[go: up one dir, main page]

EP1466312B1 - Verfahren zur signalisierung des haltewunsches an einer bedarfshaltestelle - Google Patents

Verfahren zur signalisierung des haltewunsches an einer bedarfshaltestelle Download PDF

Info

Publication number
EP1466312B1
EP1466312B1 EP02792577A EP02792577A EP1466312B1 EP 1466312 B1 EP1466312 B1 EP 1466312B1 EP 02792577 A EP02792577 A EP 02792577A EP 02792577 A EP02792577 A EP 02792577A EP 1466312 B1 EP1466312 B1 EP 1466312B1
Authority
EP
European Patent Office
Prior art keywords
stop
bus
request
central server
optional
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
EP02792577A
Other languages
English (en)
French (fr)
Other versions
EP1466312A1 (de
Inventor
Klaus Rapf
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to AT02792577T priority Critical patent/ATE319153T1/de
Publication of EP1466312A1 publication Critical patent/EP1466312A1/de
Application granted granted Critical
Publication of EP1466312B1 publication Critical patent/EP1466312B1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/123—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams
    • G08G1/127—Traffic control systems for road vehicles indicating the position of vehicles, e.g. scheduled vehicles; Managing passenger vehicles circulating according to a fixed timetable, e.g. buses, trains, trams to a central station ; Indicators in a central station

Definitions

  • the determination of the bus is done automatically by the central server.
  • the necessary personnel expenses can be reduced to virtually zero. Due to the automatic assignment by the server, the time required for the assignment is reduced in comparison to the manual allocation.
  • the confirmation preferably forwarded to the expected arrival time of the bus or the remaining waiting time to the operating unit and displayed there. In this way, the passenger can be informed whether, or at what time, the next bus will approach the request stop.
  • the special functionality of the signaling device can be programmed via the platform-independent language Java. Using Java results in the best possible portability of the software code to other devices or mobile phones.
  • Fig. 1 shows a route 5 with multiple stops 3 and a demand stop 1, which is accessible via a route section 6.
  • the request stop 1 should be approached by the bus 2 only if a passenger of the bus 2 wants to get off at this request stop 1 or if a passenger wants to get on the request stop 1 in the bus 2. In the first case, the passenger can tell the stop request directly to the bus driver.
  • the inventive method provides that the passenger transmits a first signal 7 to a central server 4 and that this central server 4 forwards the hold request to the bus 2, whereupon the bus driver approaches the request stop 1.
  • the stop request can be transmitted by the passenger in different ways to the central server. Preferably, the transmission takes place via mobile radio.
  • the passenger can transmit the stop request to the central server 4, for example via SMS, stating the stop number corresponding to the request stop 1.
  • An essential feature of the presented solution is that the communication processes and the selection of the bus 2 can be handled without additional personnel expenses.
  • the bus driver can confirm the receipt. This confirmation is sent to the central server 4 and from there to Passenger forwarded, with additional information, such as the remaining waiting time can be transferred with.
  • FIG. 2 shows a flow chart of the interaction of the passenger with the operating unit 18 of the request stop 1.
  • configuration data is requested from the central server and transferred to the memory of the request stop 1.
  • the passenger Usually in 103 the passenger a short welcome text or a short information is offered. If the passenger presses the button 11 at 104, the information about the hold request at 105 is normally forwarded to the server and the server's response is waited at 106.
  • the passenger is notified of the expected time of arrival at 107, 108 or 109; or else it is indicated at 110 that no bus can approach the demand stop 1 on that day.
  • the point 109 will be traversed if the earliest bus 2 can not arrive until after a considerable waiting time, at which point the passenger must confirm at 111 that he really wishes to order that bus. This confirmation is forwarded at 112 to the central server. Otherwise, at 107 and 108, only the expected time of arrival is displayed because the bus has already been requested by the server. After an adjustable waiting time at 115, after which the bus has already reached the demand stop 1 in the normal case, the system returns to its original state 103.
  • special messages for example, at 117 the message about a low state of charge of the battery of the demand stop 1, can be transmitted to the central server 4.
  • Fig. 3 shows the sequence of interaction of the bus driver with the signaling device 40 in the bus 2. This consists for example of a standard mobile phone with JAVA programming environment.
  • the thick arrows symbolize process steps in which a data transmission between the signaling device 40 and the central server 4 takes place.
  • the bus driver is asked at 301 to log in to the system. If the login is successful, the main menu of the application appears at 302 after a short welcome message. From this main menu, the bus driver can, on the one hand, make certain settings by selecting a menu item at 303 or the current list of the on-demand stop 1 can be displayed at 304.
  • passengers may be notified in bus 2 to the central server 4 at 310. If the bus driver has to approach a request stop 1 because a passenger wishes to leave the bus 2 there, this is communicated to the central server 4. This can be used to fine tune the timetable or to display at the request stop 1 that the next bus 2 will arrive shortly.
  • the bus driver can log out of the system via a menu item at 311.
  • Incoming requests are first checked for admissibility at 204 by matching with a user database 205 and stored in the list of existing requests.
  • This list of existing requests is referred to as marketplace 205.
  • the marketplace 205 is preferably provided with JMS (Java Messaging Service).
  • JMS Java Messaging Service
  • the architecture of the central server 4 is kept open and envisages that several carriers or multiple providers can access this marketplace 205 through provider modules 207 and make offers for the individual requests.
  • the vendor module 207 reads the request or the hold request from the marketplace 205 and determined by matching with a timetable database 209 for the stop request at the request stop 1 candidate bus 2.
  • the demand stop 1, the central server 4 and the signaling device 40 in the bus 2 thus form a traffic system which is used for the signaling method according to the invention.
  • the electronic components are housed in Fig. 6 in a cabinet 10 which is closable by means of a lock 13.
  • the cabinet 10 serves to protect the electronics from the weather.
  • This cabinet 10 is mounted on the mast 17, on which a GSM antenna 15 is mounted. Furthermore, 17 power and signal lines are performed in the mast.
  • the communication unit 19 of the demand station 1 comprises a GSM modem 20 and a GSM antenna 15.
  • the antenna 15 is used to establish the radio link between the communication unit 19 of the demand station 1 and a base station of the mobile service provider. Due to the possible local implementation of base stations, a simple rod antenna is preferably used.
  • the GSM antenna 15 is mounted in the upper part of the mast 17 in order to obtain a favorable radiation behavior and not expose the passenger to excessive radiation load.
  • the limits for radiofrequency field exposure are set by the ICNTRP (International Commission on Non-Ionizing Radiation Protection) and adopted by WHO or most governments.
  • the limit recommended by IC-NIRP is 5000 mW / m 2 for 1000 MHz (GSM900) and 9000 mW / m 2 for 1800 MHz.
  • a remote GSM antenna 15 is preferably used in about 3m height.
  • the demand stop 1 further has a likewise mounted on the mast 17 solar panel 14.
  • the solar panel 14 is part of the power supply of the BH 1 and makes it possible to set the demand stop 1 independently of an external power supply.
  • the solar panel 14 supplies a battery via a charge controller.
  • the solar panel 14 is mounted so that a clearance height of about 2.4m is ensured. During assembly, it is secured against rotation in such a way that optimal exposure / exposure can take place.
  • amorphous modules are selected for the solar panel. Due to the slightly higher voltages of the amorphous modules, the charge controller has a higher voltage available.
  • Fig. 7a shows on the left the GSM modem 20, in this case a Motorola g18 with the mmcx FME antenna adapter 20 'going to the left.
  • the modem 20 is connected via a laminated ribbon cable 21 with a miniature connector of the board 22 and further to the power supply and the computer 23.
  • the modem 20 or the communication unit is used for bidirectional transmission of information between the demand station 1 and the central server.
  • the display 12 in this case a Batron 42008 is shown, which is connected via a data line 28 and a separate cable for the power supply for the backlight with the board 22. Also shown is a cover 24 for shielding the computer 23.
  • Fig. 8 shows the board 22 with mounted on-board computer 23, which has its own processor, a memory and the necessary I / O ports.
  • the board 22 is connected via the terminals 25 to the supply voltage.
  • the display 12 is connected on the one hand via the data line 28 and a separate cable 26 for the power supply for the backlight with the board 22.
  • an NTC temperature sensor via the line 32 to the board 22 is connected.
  • the computer 23 contains the logic for communication with the user via the buttons 11 and the display 12 and the communication based thereon with the central server 4 via the GSM modem 20.
  • the computer 23 can be used to acquire a wide variety of measured values or data.
  • the computer 23 can be used to acquire a wide variety of measured values or data.
  • only one motion detector 16 is connected, but different data, such as the different measurement results in a
  • Weather station detected by the computer 23 and forwarded to a central server 4.
  • the computer preferably has further options such as code reloading during operation, an internal clock, JAVA support, publicly available libraries for the peripherals, low level classes for RS232, I / O ports, sensors and communication - tcp / ip PPP (Point to Point Protocol).
  • this processor acts as a computer 23.
  • microprocessors ⁇ P's
  • single board computers such as the described JSTAMP or native Java processors
  • a ⁇ C or GSM module with built-in 64kByte Flash RAM for user code and TCP / IP stack e.g., the ⁇ WEB GSM 10.
  • the presented demand stop 1 can also be used to record a wide variety of measured values or data and forward them to a central server 4.
  • the hitherto treated motion sensor, the temperature sensor and the probe 11 are different measuring devices 18, which are queried by the computer 23. This data is forwarded to the central server 4, wherein the power supply by means of solar panel 14 allows to use the data acquisition device independently of external power supplies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Time-Division Multiplex Systems (AREA)

Description

  • Die Erfindung betrifft ein Signalisierungsverfahren zur Signalisierung des Haltewunsches an einer Bedarfshaltestelle einer Fahrtstrecke eines Transportunternehmens, vorzugsweise eines Bus-Transportunternehmens, wobei die Bedarfshaltestelle nur im Falle eines gewünschten Einstieges/Ausstieges eines Fahrgastes angefahren wird, wobei der Haltewunsch über eine Bedienungseinheit eingegeben wird, und ein erstes Signal generiert wird, welches den Haltewunsch und eine Information über die Identität der Bedarfshaltestelle beinhaltet, dieses erste Signal durch ein Sendemodul an zumindest einen zentralen Server übertragen wird, der zentrale Server jenen Bus ermittelt, der die Bedarfshaltestelle am ehesten zum gewünschten Haltezeitpunkt anfahren kann und den Haltewunsch an diesen Bus übermittelt, indem er diesem Bus ein zweites Signal sendet, welches dem Busfahrer über eine Signalisierungseinrichtung signalisiert wird.
  • Viele regionale Kraftfahrlinien zeichnen sich dadurch aus, dass mittels sogenannter Stichfahrten, also der Abweichung in der Streckenführung der Hauptroute zwar die Erschließungsqualität verbessert wird, zugleich aber durch die Fahrzeiterhöhung die Attraktivität für die Mehrzahl der Gäste sinkt.
  • Um diesem Problem vorzubeugen, sind Lösungen vorgeschlagen worden, bei denen eine Haltestelle nur dann angefahren wird, wenn hierfür auch wirklich Bedarf besteht. Diese bekannten Lösungen sind jedoch mit zusätzlichem Personalaufwand verbunden.
  • In der US 6 006 159 A wird ein System offenbart, das Passagiere, die auf öffentliche Verkehrsmittel warten, über den Status dieser Verkehrsmittel, insbesondere Ankunftszeiten, informiert. Die aktuelle Position der Fahrzeuge wird hierbei mit GPS ermittelt. Über einen zentralen Computer werden sodann die Durchfahrtszeiten an den Haltestellen errechnet. Weiters wird auch beschrieben, dass die Stromversorgung an der Haltestelle mittels Solarenergie und back-up-battery erfolgen kann und dass tragbare Einrichtungen, wie z.B. Telefone, ebenfalls Informationen vom zentralen Computer empfangen können.
  • Die DE 197 21 145 A betrifft ein Verfahren zur Durchführung des öffentlichen Personennahverkehrs (ÖPNV), wobei Fahrzeuge des ÖPNV mit einer die Fahrzeugeinsätze überwachenden Zentrale in Funkverbindung stehen und Fahrzeugeinsätze als individueller Fahrdienst dem Bedarf entsprechend geplant werden. Hierbei ist an der jeweiligen Starthaltestelle eine Eingabe-Einrichtung vorgesehen, über die der Fahrgast per Sende/Empfangseinrichtung mit bilateraler Funkverbindung die gewünschte Ziel-Haltestelle an die Zentrale übermittelt und daraufhin die geschätzte Ankunftszeit des Fahrzeugs an die Start-Haltestelle übertragen wird. Weiters wird zur Kommunikation der Zentrale mit den Fahrzeugen ein rechnergestütztes Betriebsleitsystem benannt.
  • Nachteilig an der Einrichtung der DE 197 21 145 A und auch der US 6 006 159 A ist, dass die Kommunikation des Busfahrers kaum nachvollziehbar ist und bei ausbleibender Reaktion des Busfahrers keine geeignete Aktion gesetzt werden kann, dem Haltewunsch eines Fahrgasts nachzukommen.
  • Unter Berücksichtigung des Standes der Technik wird als Aufgabe der vorliegenden Erfindung angesehen, ein Signalisierungsverfahren gemäß Oberbegriff des Patentanspruchs 1 anzugeben, bei dem die bekannten Nachteile vermieden werden, das ohne bzw. mit minimalem zusätzlichem Personalaufwand durchgeführt werden kann und bei dem die Reaktion eines Busfahrers auf einen Haltewunsch in das Verfahren einbezogen wird.
  • Erfindungsgemäß wird dies dadurch erreicht, dass der Busfahrer den Erhalt des Haltewunsches bestätigt und die Bestätigung an den zentralen Server weitergeleitet wird. Dadurch, dass der Haltewunsch an einen zentralen Server übertragen wird und nicht an alle in Frage kommende Busse, wird die Netzlast minimiert. Der Server sucht lediglich einen in Frage kommenden Bus aus und übermittelt nur diesem den Haltewunsch. Dadurch, dass der Haltewunsch im zentralen Server rechnerisch erfasst wird, ergibt sich zusätzlich die Möglichkeit der einfachen Protokollierung und nachträglichen Auswertung der Haltewünsche. Weiters erlaubt es die computergesteuerte Verarbeitung der Haltewünsche, den Personalaufwand gering zu halten. Weiters kann die Kommunikation mit dem Busfahrer genauer protokolliert werden. Auch ergibt sich die Möglichkeit, abhängig von der Bestätigung des Busfahrers oder bei Ausbleiben einer solchen Bestätigung, bestimmte Aktionen zu setzen. Beispielsweise kann bei fehlender Bestätigung durch einen Busfahrer der Haltewunsch vom zentralen Server an den nächsten in Frage kommenden Busfahrer weitergeleitet werden.
  • Bei einer weiteren Ausgestaltung der Erfindung kann vorgesehen sein, dass die Übermittlung des ersten und/oder des zweiten Signals über ein Mobilfunk-Protokoll, insbesondere über GSM bzw. über GPRS oder UMTS erfolgt. Durch die Verwendung der existierenden flächendeckenden Mobilfunknetze müssen keine speziellen Infrastukturmaßnahmen gesetzt werden. Der Standard GPRS ermöglicht dabei eine dauerhafte Netzwerkverbindung zwischen der Bedarfshaltestelle, dem zentralen Server und dem Bus.
  • In weiterer Ausgestaltung der Erfindung kann vorgesehen sein, dass die Ermittlung des Busses durch den zentralen Server automatisch erfolgt. Damit kann der notwendige Personalaufwand praktisch auf Null reduziert werden. Durch die automatische Zuordnung durch den Server wird darüber hinaus die für die Zuordnung notwendige Dauer im Vergleich zur manuellen Zuordnung verringert.
  • Nach einer anderen Variante der Erfindung kann vorgesehen sein, dass der zentrale Server den Bus aus der Position der Bedarfshaltestelle und den Fahrplan-Daten ermittelt, indem überprüft wird, welcher Bus laut Fahrplan die Bedarfshaltestelle am ehesten zum gewünschten Haltezeitpunkt anfahren könnte. Dies stellt eine besonders einfache Methode zur automatischen Zuordnung der Busse zu den Haltewünschen dar.
  • Bei einer weiteren Ausgestaltung der Erfindung kann vorgesehen sein, dass der zentrale Server den Bus aus der Position der Bedarfshaltestelle und den aktuellen Koordinaten aller bzw. mehrerer Busse ermittelt, indem die Koordinaten aller Busse insbesondere über GPS abgefragt werden, die die Bedarfshaltestelle laut Fahrplan anfahren können, und überprüft wird, welcher Bus die Bedarfshaltestelle am ehesten zum gewünschten Haltezeitpunkt anfahren könnte. Durch diese Methode können temporäre Störungen im Ablauf des Fahrplans bei der Zuordnung der Busse zu den Haltewünschen berücksichtigt werden. Weiters kann dem Fahrgast die zu erwartende Ankunftszeit genauer mitgeteilt werden.
  • Bei einer weiteren Ausgestaltung der Erfindung kann vorgesehen sein, dass die Bestätigung, vorzugsweise mit der zu erwartenden Ankunftszeit des Busses bzw. der noch verbleibenden Wartezeit, an die Bedienungseinheit weitergeleitet und dort angezeigt wird. Dadurch kann dem Fahrgast mitgeteilt werden ob, bzw. zu welcher Zeit der nächste Bus die Bedarfshaltestelle anfahren wird.
  • Schließlich umfasst die Erfindung ein Verkehrssystem für ein Transportunternehmen, insbesondere Bus-Transportunternehmen, vorgesehen zur Durchführung des Signalisierungsverfahrens nach einem der Ansprüche 1 bis 6, umfassend zumindest eine Bedarfshaltestelle, welche nur im Falle eines gewünschten Einstieges/Ausstieges eines Fahrgastes angefahren wird, zumindest einen zentralen Server und zumindest eine Signalisierungseinrichtung in einem Fahrzeug bzw. Bus des Transportunternehmens, wobei die Bedarfshaltestelle eine Bedienungseinheit zur Eingabe eines Haltewunsches und ein Sendemodul zur Übermittlung des Haltewunsches an den zentralen Server umfasst, der zentrale Server ein Kommunikationsmodul zum Datenaustausch mit der Bedarfshaltestelle und der Signalisierungseinrichtung aufweist, wobei die Signalisierungseinrichtung dazu vorgesehen ist, dass der Busfahrer damit den Erhalt des Haltewunsches bestätigt und die Bestätigung an den zentralen Server weitergeleitet wird, wobei die Signalisierungseinrichtung durch ein Java programmierbares Mobiltelefon realisiert ist.
  • Damit können Haltewünsche automatisch von der Bedarfshaltestelle an den zentralen Server und von diesen an den in Frage kommenden Bus übermittelt werden, wobei handelsübliche Geräte als Signalisierungseinrichtung eingesetzt werden können. Die spezielle Funktionalität der Signalisierungseinrichtung kann über die plattformunabhängige Sprache Java programmiert werden. Durch Verwendung von Java ergibt sich eine bestmögliche Portabilität des Softwarecodes auf andere Geräte oder Mobiltelefone.
  • Die Erfindung wird unter Bezugnahme auf die beigeschlosseneri Zeichnungen, in welchen besonders bevorzugte Ausführungsbeispiele dargestellt sind, näher beschrieben. Dabei zeigt:
    • Fig. 1 eine Prinzipskizze des erfindungsgemäßen Signalisierungsverfahrens;
    • Fig. 2 ein Ablaufdiagramm der Software in der Bedarfshaltestelle 1;
    • Fig. 3 ein Ablaufdiagramm der Software in der Signalisierungseinrichtung 19 des Busses;
    • Fig. 4 ein Struktogramm der Kommunikationsabläufe zwischen Bedarfshaltestelle 1, zentralem Server 4 und Bus 2;
    • Fig. 5 ein zeitliches Ablaufdiagramm der Kommunikationsabläufe zwischen Bedarfshaltestelle 1, zentralem Server 4 und Bus 2;
    • Fig. 6 eine erfindungsgemäße Bedarfshaltestelle 1 in Gesamtansicht;
    • Fig. 7a die elektronischen Komponenten der erfindungsgemäßen Bedarfshaltestelle 1 in Fig. 6;
    • Fig. 7b eine Ansicht des Displays 11 und des Bewegungsmelders 16, und
    • Fig. 8 die Platine 22 eines erfindungsgemäßen Bedarfshaltestelle 1.
  • Fig. 1 zeigt eine Fahrtstrecke 5 mit mehreren Haltestellen 3 und einer Bedarfshaltestelle 1, die über einen Fahrtstreckenabschnitt 6 erreichbar ist. Die Bedarfshaltestelle 1 soll vom Bus 2 nur dann angefahren werden, wenn ein Fahrgast des Busses 2 an dieser Bedarfshaltestelle 1 aussteigen möchte oder wenn ein Fahrgast an der Bedarfshaltestelle 1 in den Bus 2 zusteigen möchte. Im ersten Fall kann der Fahrgast den Haltewunsch direkt dem Buslenker mitteilen.
  • Für den zweiten Fall sieht das erfindungsgemäße Verfahren vor, dass der Fahrgast ein erstes Signal 7 an einen zentralen Server 4 übermittelt und dass dieser zentrale Server 4 den Haltewunsch an den Bus 2 weiterleitet, woraufhin der Busfahrer die Bedarfshaltestelle 1 anfährt.
  • Unterschiedlich zu anderen Systemen wie zum Beispiel Sammeltaxis handelt es sich beim vorgeschlagenen System um einen Linienbandbetrieb mit einer genau definierten Abfolge von Haltestellen 3, wobei die Bedarfshaltestelle 1 nur bei Bedarf angefahren wird.
  • Der Haltewunsch kann vom Fahrgast auf unterschiedliche Arten an den zentralen Server übermittelt werden. Vorzugsweise erfolgt die Übermittlung über Mobilfunk. Der Fahrgast kann den Haltewunsch beispielsweise über SMS unter Angabe der der Bedarfshaltestelle 1 entsprechenden Haltestellennummer an den zentralen Server 4 übermittelt.
  • Eine andere vorteilhafte Möglichkeit besteht darin, daß der Fahrgast eine Bedienungseinheit 18, insbesondere einen Taster 11 unmittelbar an der Bedarfshaltestelle 1 betätigt und der Haltewunsch von der Bedarfshaltestelle 1, beispielsweise über GPRS, an den zentralen Server 4 übermittelt wird. In diesem Fall wird die Information über die geographische Lage der Bedarfshaltestelle 1, beispielsweise über eine eindeutige Haltestellennummer, automatisch mit an den zentralen Server 4 übertragen. Die Position der Bedarfshaltestelle 1 ist vorzugsweise über eine eindeutige Haltestellennummer kodiert, die jeder Haltestelle 3 bzw. Bedarfshaltestelle 1 zugeordnet ist. Wesentlich ist, daß eine eindeutige Identifikation der Bedarfshaltestelle 1 möglich ist.
  • Natürlich kann auch ein herkömmliches Funknetz oder auch die Übertragung über Kabel verwendet werden, um den Haltewunsch an den zentralen Server 4 zu übermitteln. Die Verwendung des GSM Netzes bietet jedoch den Vorteil eines bereits existierenden flächendeckend ausgebauten Netzes. Weiters ist die Aufteilung der Last auf mehrere zentrale Server 4 möglich.
  • Aus der Haltestellennummer bzw. aus den Daten über die Position der Bedarfshaltestelle 1 und dem gewünschten Haltezeitpunkt ermittelt der zentrale Server 4 den Bus 2, der die Bedarfshaltestelle 1 am ehesten zum Haltezeitpunkt anfahren kann.
  • Der Haltezeitpunkt ist beispielsweise der Zeitpunkt der Abgabe des Haltewunsches, es ist aber auch möglich, daß der Fahrgast seinen Haltewunsch per SMS bereits am Tag zuvor abgibt oder einen bestimmten späteren Haltezeitpunkt wählt.
  • Vorzugsweise wird der in Frage kommende Bus 2 durch den zentralen Server 4 automatisch ermittelt. Dies geschieht am einfachsten durch den automatisierten Abgleich mit den Fahrplan-Daten. Der zentrale Server 4 überprüft dabei, welcher Bus 2 die Bedarfshaltestelle 1 laut Fahrplan am ehesten zum gewünschten Haltezeitpunkt anfahren könnte. Anschließend wird der Haltewunsch vom zentralen Server 4 an diesen Bus 2 weitergeleitet, woraufhin der Busfahrer die Bedarfshaltestelle 1 anfährt.
  • Da durch das flexible System der Bedarfshaltestelle 1 die Busse 2 manchmal nicht exakt nach Fahrplan fahren, bietet sich vorteilhaft die Möglichkeit einer genauen Abstimmung mit der tatsächlichen Position der Busse. Für diesen Fall werden die aktuellen Positionsdaten in jedem Bus 2 laufend über GPS abgefragt und beispielsweise per SMS oder GPRS an den zentralen Server 4 übermittelt. Die Auswahl des der Bedarfshaltestelle 1 am nächsten liegenden Busses 2 erfolgt dann mittels Abgleich der tatsächlichen Positionen der Busse 2.
  • Wesentliches Merkmal der vorgestellten Lösung ist, daß die Kommunikationsvorgänge und die Auswahl des Busses 2 ohne zusätzlichen Personalaufwand abgewickelt werden können.
  • Nach Übermittlung des Haltewunsches an den betreffenden Bus 2 kann der Busfahrer den Erhalt bestätigen. Diese Bestätigung wird an den zentralen Server 4 und von dort zum Fahrgast weitergeleitet, wobei zusätzliche Informationen, wie die zu verbleibende Wartezeit mit übertragen werden können.
  • Fig 2 zeigt ein Ablaufdiagramm der Interaktion des Fahrgastes mit der Bedienungseinheit 18 der Bedarfshaltestelle 1. Bei der erstmaligen Inbetriebnahme oder beim Einschalten der Bedarfshaltestelle 1 werden in den Schritten 101 und 102 Konfigurationsdaten vom zentralen Server angefragt und in den Speicher der Bedarfshaltestelle 1 übertragen. Für gewöhnlich wird in 103 dem Fahrgast ein kurzer Begrüßungstext oder eine Kurzinformation angeboten. Betätigt der Fahrgast den Taster 11 bei 104 wird im Regelfall b die Information über den Haltewunsch bei 105 an den Server weitergeleitet und die Antwort des Servers bei 106 abgewartet. Abhängig von der Antwort des zentralen Servers 4 wird dem Fahrgast die zu erwartende Ankunftszeit bei 107, 108 oder 109 angezeigt; oder aber es wird bei 110 angezeigt, daß an dem betreffenden Tag kein Bus mehr die Bedarfshaltestelle 1 anfahren kann. Der Punkt 109 wird durchlaufen, falls der früheste Bus 2 erst nach einer beträchtlichen Wartezeit eintreffen kann, worauf der Fahrgast bei 111 bestätigen muß, daß er diesen Bus tatsächlich bestellen möchte. Diese Bestätigung wird bei 112 an den zentralen Server weitergeleitet. Ansonsten wird bei 107 und 108 lediglich die zu erwartende Ankunftszeit angezeigt, da der Bus bereits durch den Server angefordert wurde. Nach einer einstellbaren Wartezeit bei 115, nach der der Bus im Normalfall die Bedarfshaltestelle 1 bereits erreicht hat, kehrt das System in seinen Ursprungszustand 103 zurück.
  • Um den Netzverkehr im Mobilfunknetz zu minimieren kann vorgesehen sein, daß der Fahrplan der entsprechenden Buslinie in einer Recheneinheit 23 bzw. im Speicher der Bedarfshaltestelle 1 abgelegt ist. In diesem Fall kann der nächste in Frage kommende Bus unmittelbar von der Bedarfshaltestelle 1 ermittelt werden. Nach Drücken des Tasters 11 durch den Fahrgast bei 104 wird über den Weg a der nächste Bus bei 109 angezeigt, bzw. bei 110 eine Meldung, daß an diesem Tag kein Bus mehr fährt. Der Fahrgast kann wieder über 111 bestätigen, daß er diesen Bus bestellen möchte, oder die Bestellung bei 113 abbrechen, welche Information bei 114 an den zentralen Server 4 übermittelt wird.
  • Bei einigen Bedarfshaltestellen 1, beispielsweise Mehrfachhaltestellen, können mehrere Anfragen für unterschiedliche Buslinien bzw. für unterschiedliche gewünschte Fahrtrichtungen der selben Buslinie eingegeben werden. Hierfür können mehrere Taster 11 vorgesehen werden. Ob ein korrekter Taster 11 vom Fahrgast betätigt wurde, wird in 116 abgefragt. Nur bei korrekter Eingabe wird diese weiterbehandelt
  • Zusätzlich zu dem beschriebenen Ablauf können spezielle Meldungen, beispielsweise bei 117 die Meldung über einen niedrigen Ladezustand der Batterie der Bedarfshaltestelle 1, an den zentralen Server 4 übermittelt werden.
  • Fig. 3 zeigt den Ablauf der Interaktion des Busfahrers mit der Signalisierungseinrichtung 40 im Bus 2. Diese besteht beispielsweise aus einem handelsüblichem Mobiltelefon mit JAVA Programmierumgebung. Die dicken Pfeile symbolisieren dabei Ablaufschritte, bei denen eine Datenübertragung zwischen der Signalisierungseinrichtung 40 und dem zentralen Server 4 erfolgt.
  • Nach dem Programmstart wird der Busfahrer bei 301 aufgefordert, sich beim System anzumelden. Ist die Anmeldung erfolgreich, erscheint nach einer kurzen Willkommensnachricht das Hauptmenü der Applikation bei 302. Von diesem Hauptmenü aus kann der Busfahrer einerseits durch Wahl eines Menüpunktes bei 303 bestimmte Einstellungen tätigen oder sich bei 304 die aktuelle Liste der anzufahrenden Bedarfshaltestelle 1 anzeigen lassen.
  • Sobald ein Haltewunsch für eine bestimmte Bedarfshaltestelle 1 im zentralen Server 4 eingeht und der zentrale Server 4 diesen Bus 2 ausgewählt hat, wird der Fahrer durch ein akustisches Signal benachrichtigt. Der Fahrer fordert daraufhin den oder die neuen Haltewünsche vom zentralen Server 4 an. Der oder die neuen Haltewünsche werden in einer Schleife abgearbeitet, wobei der Fahrer für jeden Haltewunsch bei 307, 308 oder 309 angeben kann, ob er die betreffende Bedarfshaltestelle 1 anfahren kann oder nicht, bzw. mit welcher Verspätung. Diese Antworten des Busfahrers werden an den Server 4 übermittelt. Sind alle Haltewünsche abgearbeitet, geht das System in die Grundstellung 302 zurück.
  • Zusätzlich können bei 310 Austeigewünsche der Passagiere im Bus 2 dem zentralen Server 4 mitgeteilt werden. Muß der Busfahrer eine Bedarfshaltestelle 1 anfahren, weil ein Passagier dort den Bus 2 verlassen möchte, wird dies dem zentralen Server 4 mitgeteilt. Dies kann zu Feinabstimmungen des Fahrplans verwendet werden oder auch zur Anzeige an der Bedarfshaltestelle 1, daß der nächste Bus 2 in Kürze eintreffen wird.
  • Am Ende seines Dienstes kann sich der Busfahrer über einen Menüpunkt bei 311 aus dem System ausloggen.
  • Fig. 4 verdeutlicht die Architektur des zentralen Servers 4 und die Verbindungen zwischen dem zentralen Server 4, dem Bus 2 und der Bedarfshaltestelle 1. Die Kommunikation erfolgt über ein Kommunikationsmodul 202, welches beispielsweise über GPRS mit der Signalisierungseinrichtung 40 im Bus 2 und der Bedarfshaltestelle 1 Daten austauschen kann. Weiters werden vom Fahrgast abgesandte SMS zunächst an das Kommunikationsmodul 202 geleitet. Dieses Kommunikationsmodul 202 kommuniziert mit dem zentralen Server 4 über ein definiertes Protokoll, beispielsweise XML, wobei die ein- und ausgehenden Nachrichten bei 203 in ein vom Server verwendetes Format übersetzt werden. Zusätzlich können Anfragen auch auf andere Art, beispielsweise über eine Web Oberfläche und ein JAVA Servlet 208 eingegeben und an den zentralen Server 4 weitergeleitet werden.
  • Ankommende Anfragen werden zunächst bei 204 durch Abgleich mit einer Benutzerdatenbank 205 auf deren Zulässigkeit überprüft und in der Liste der vorhandenen Anfragen abgelegt. Diese Liste der vorhandenen Anfragen wird als Marktplatz 205 bezeichnet. Der Marktplatz 205 ist vorzugsweise mit JMS (Java Messaging Service versehen). Die Architektur des zentralen Servers 4 ist offen gehalten und sieht vor, daß mehrere Transportunternehmen bzw. mehrere Anbieter durch Anbietermodule 207 auf diesen Marktplatz 205 zugreifen können und Angebote zu den einzelnen Anfragen abgeben können. Im einfachsten Fall eines einzigen Anbieters liest das Anbietermodul 207 die Anfrage bzw. den Haltewunsch vom Marktplatz 205 aus und ermittelt durch Abgleich mit einer Fahrplandatenbank 209 den für den Haltewunsch an der Bedarfshaltestelle 1 in Frage kommenden Bus 2.
  • Fig. 5 skizziert den Kommunikationsablauf zwischen den einzelnen Modulen des zentralen Servers 4 und dem Bus 2. Die Ermittlung des nächsten Busses 2 erfolgt im zentralen Server 4 auf der Ebene des Anbietermodules 207 im Punkt 401. In der Fahrplandatenbank 209 sind vorzugsweise alle möglichen Haltezeiten der einzelnen Busse 2 an sämtlichen Bedarfshaltestellen 1 verzeichnet. Aus dieser Datenbank wird der nächste Bus 2 durch Vergleich mit der gewünschten Haltezeit ermittelt. Ist die Zeitspanne zwischen der Benachrichtigung des Busfahrers und der gewünschten Haltezeit sehr kurz, kann es möglich sein, daß der Busfahrer die Station nicht mehr anfahren kann, da beispielsweise die entsprechende Autobahnausfahrt bereits passiert wurde. In diesen knappen Fällen ist es notwendig, im Punkt 402 beim Busfahrer nachzufragen, ob er die Bedarfshaltestelle 1 noch erreichen kann. Ist die geplante Ankunftszeit hingegen sicher zu bewerkstelligen, ist lediglich eine Benachrichtigung des Busfahrers bei 403 notwendig, woraufhin dieser die Bedarfshaltestelle 1 anzufahren hat.
  • Die Bedarfshaltestelle 1, der zentraler Server 4 und die Signalisierungseinrichtung 40 im Bus 2 bilden somit ein Verkehrssystem, welches für das erfindungsgemäße Signalisierungsverfahren verwendet wird.
  • Im folgenden wird eine vorteilhafte Ausführungsform einer Bedarfshaltestelle 1 zur Durchführung des erfindungsgemäßen Verfahrens anhand eines konkreten Beispiels näher besprochen.
  • Die in Fig. 6 dargestellte Bedarfshaltestelle 1 weist eine Bedienungseinheit 18 auf, die einen Taster 11 und ein als Display 12 ausgebildetes Anzeigemodul aufweist. Als Taster 11 können unter anderem Tastenfelder, Türöffner-Typen mit großem beleuchteten Tastenfeld ohne bewegte Teile, oder Druckknöpfe, beispielsweise der Omron Drucktaster A22 IP65 zur Verwendung kommen. Die Größe und Anzahl der Taster 11 muss dabei auf die Bedienlogik und die Displaygröße abgestimmt werden. Werden die Optionen in verschiedene Zeilen geschrieben, so ist der Tasterdurchmesser vorzugsweise nicht wesentlich größer als eine Zeilenhöhe. Aufgrund der guten Anordnungsmöglichkeit werden in Fig. 6 kleine Taster 11 verwendet, die rechts vom Display 12 montiert werden können. Die dargestellten Taster sind aus Metall und daher gegen Vandalimus geschützt. Die Taster haben aus Stromspargründen separat ansteuerbare LED's. Neben den beschriebenen Tastern 11 sind aber natürlich auch andere Bedienungseinheiten 18, beispielsweise Sensoren für Spracheingabe, durch die der Fahrgast den Haltewunsch signalisieren kann.
  • An das Display 12 werden besonders hohe Anforderungen hinsichtlich Erkennbarkeit, Kosten, Stromverbrauch und Kontrastregelung gestellt. Es können unterschiedliche Grafikdisplays oder alphanumerische Displays verwendet werden. Das dargestellte Display 12 ist ein Textdisplay mit LED Hintergrundbeleuchtung. Die Einstellung des Kontrastes erfolgt vorzugsweise in Abhängigkeit der Außentemperatur. In diesem Fall wird für die temperaturabhängige Kontraststeuerung eine eigene Schaltung verwendet.
  • Aufgrund des Stromverbrauchs wird die Beleuchtungsdauer des Displays 12 vorzugsweise möglichst kurz gehalten. Aus diesem Grund weist die Bedarfshaltestelle 1 einen auf dem Mast 17 montierten Bewegungsmelder 16 auf, der mit dem Anzeigemodul bzw. mit dem Display 12 über die Recheneinheit 23 verbunden ist. Der Bewegungsmelder detektiert Personen, die sich in der Nähe der Haltestelle aufhalten. Durch den Bewegungsmelder 16 wird die Anzeige auf dem Display 12 nur aktiviert, wenn ein Fahrgast in den Bereich der Bedarfshaltestelle 1 tritt. Vorzugsweise wird ein Bewegungsmelder 16 für Außenaufstellung mit niedrigem Grundverbrauch gewählt.
  • Zusätzlich ist im Bewegungsmelder 16 ein lichtempfindliches Element vorgesehen, um die Umgebungshelligkeit zu messen und um entscheiden zu können, ob das LCD Display 12 beleuchtet werden muss oder nicht. Durch die Einstellung auf Nachbetrieb sind Fehlauslösungen durch reflektierte Sonneneinstrahlung nicht relevant.
  • Die elektronischen Komponenten sind in Fig. 6 in einem Schrank 10 untergebracht, der mittels eines Schlosses 13 verschließbar ist. Der Schrank 10 dient dazu, die Elektronik vor Witterungseinflüssen zu schützen. Dieser Schrank 10 ist an dem Mast 17 montiert, auf welchem auch eine GSM Antenne 15 angebracht ist. Weiters werden im Mast 17 Strom und Signalleitungen geführt.
  • Die Kommunikationseinheit 19 der Bedarfshaltestelle 1 umfaßt ein GSM Modem 20 und eine GSM Antenne 15. Die Antenne 15 dient zur Herstellung der Funkverbindung zwischen der Kommunikationseinheit 19 der Bedarfshaltestelle 1 und einer Basisstation des Mobilfunkanbieters. Aufgrund der möglichen örtlichen Umsetzung von Basisstationen wird vorzugsweise eine einfache Stabantenne verwendet. Die GSM Antenne 15 wird im oberen Bereich des Mastes 17 montiert, um ein günstiges Abstrahlverhalten zu erhalten und den Fahrgast keiner zu hohen Strahlenlast auszusetzen. Die Grenzwerte für die Hochfrequenz Feld Exposition werden von der ICNTRP (International Comission on Non-Ionizing Radiation Protection) festgelegt und von der WHO bzw. den meisten Regierungen übernommen. Der von IC-NIRP empfohlene Grenzwert liegt bei 5000 mW/m2 für 1000 MHz (GSM900) und 9000 mW/m2 für 1800 MHz. Für die Einhaltung dieser Grenzwerte (IC-NIRP) wird eine abgesetzte GSM Antenne 15 in vorzugsweise etwa 3m Höhe verwendet.
  • Die Bedarfshaltestelle 1 weist weiters ein ebenfalls auf dem Mast 17 montiertes Solarpaneel 14 auf. Das Solarpaneel 14 ist Teil der Stromversorgung der BH 1 und ermöglicht es, die Bedarfshaltestelle 1 unabhängig von einer externen Spannungsversorgung aufzustellen.
  • Das Solarpaneel 14 versorgt über einen Laderegler einen Akkumulator. Vorzugsweise wird das Solarpaneel 14 so montiert, dass eine Durchgangshöhe von etwa 2,4m gewährleistet ist. Bei der Montage wird es verdrehsicher derart befestigt, dass eine optimale Besonnung/Belichtung stattfinden kann.
  • Vorzugsweise werden für das Solarpaneel 14 amorphe Module gewählt. Aufgrund der etwas höheren Spannungen der amorphen Module steht dem Laderegler eine höhere Spannung zur Verfügung.
  • Vorzugsweise ist ein Laderegler zwischen Solarpaneel 14 und Akkumulator geschaltet. Dieser Laderegler sorgt dafür, dass die Ladung so erfolgt, dass der Akkumulator keinen Schaden erleidet. Zusätzlich kontrolliert der Laderegler die Entladetiefe des Akkumulators.
  • Der Akkumulator ist der zwischen Laderegler und Verbraucher angeordnete Energiespeicher, welcher eine Überbrückung der Nacht und von Perioden mit geringer Sonneneinstrahlung ermöglicht. Je nach Formfaktor des Akkumulators sind andere Gehäuse erforderlich. Bei einer Gasung des Akkumulators wird die Elektronik vorzugsweise getrennt angeordnet und das Batteriefach belüftet.
  • Im folgenden wird die Struktur der elektronischen Komponenten einer erfindungsgemäßen Bedarfshaltestelle 1 an einer konkreten Ausführungsform erläutert, wobei die Erfindung sich jedoch nicht auf die gezeigten Komponenten beschränkt.
  • Fig. 7a zeigt links das GSM Modem 20, in diesem Fall ein Motorola g18 mit dem mmcx-FME Antennenadapter 20' nach links weggehend. Das Modem 20 ist über ein laminiertes Flachbandkabel 21 mit einem Miniaturstecker der Platine 22 und weiter mit der Stromversorgung und dem Rechner 23 verbunden. Das Modem 20 bzw. die Kommunikationseinheit dient zur bidirektionalen Übertragung der Information zwischen der Bedarfshaltestelle 1 und dem zentralen Server.
  • An der oberen Seite von Fig. 7a ist das Display 12, in diesem Fall ein Batron 42008 gezeigt, welches über eine Datenleitung 28 und eine separates Kabel für die Stromversorgung für die Hintergrundbeleuchtung mit der Platine 22 verbunden ist. Weiters gezeigt ist eine Abdeckung 24 zur Abschirmung des Rechners 23.
  • Fig. 7b zeigt das Display 12 von vorne und den geöffneten 12V Infrarot Bewegungsmelder 16.
  • Fig. 8 zeigt die Platine 22 mit angebrachtem On-Board Rechner 23, welcher über einen eigenen Prozessor, einen Speicher und die notwendigen I/O Ports verfügt. Die Platine 22 ist über die Anschlüsse 25 mit der Versorgungsspannung verbunden. Das Display 12 ist einerseits über die Datenleitung 28 und eine separates Kabel 26 für die Stromversorgung für die Hintergrundbeleuchtung mit der Platine 22 verbunden.
  • Über ein Flachbandkabel 29 kann die Software zum Betrieb der Bedarfshaltestelle 1 auf den Rechner 23 gespielt werden, wobei über einen erster Jumper 33 bestimmt werden kann, ob die Daten in den flüchtigen oder den nichtflüchtigen Speicher des Rechners 23 geschrieben werden sollen.
  • Die beiden Taster 11 sind über die Leitungen 31 mit der Platine 22 verbunden.
  • Zur Steuerung des Kontrastes des Displays 12, welcher abhängig von der Außentemperatur geregelt werden muß, ist ein NTC-Temperatursensor über die Leitung 32 an die Platine 22 angeschlossen.
  • Zusätzlich ist ein weiterer Jumper 34 vorgesehen, durch den ein sogenannter Watchdog aktiviert werden kann, der die Platine in regelmäßigen Abständen in den Ursprungszustand zurücksetzt.
  • Der Rechner 23 beinhaltet die Logik für die Kommunikation mit dem Benutzer über die Taster 11 und das Display 12 und die darauf aufbauende Kommunikation mit dem zentralen Server 4 über das GSM Modem 20.
  • Natürlich sind auch zusätzliche Funktionen möglich. Beispielsweise kann der Rechner 23 dazu benutzt werden, um unterschiedlichste Messwerte oder Daten zu erfassen. Bei der dargestellten Ausführungsform ist nur ein Bewegungsmelder 16 angeschlossen, jedoch können unterschiedliche Daten, wie beispielsweise die unterschiedlichen Messergebnisse bei einer
  • Wetterstation, vom Rechner 23 erfaßt und an einen zentralen Server 4 weitergeleitet werden.
  • Vorzugsweise verfügt der Rechner über weitere Optionen wie das Nachladen von Code während des Betriebes, eine interne Uhr, JAVA Unterstützung, öffentlich verfügbare Bibliotheken für die Peripherie Low level Klassen für RS232, I/O Ports, Sensorik und Kommunikation - tcp/ip PPP (Point to Point Protocol).
  • Natürlich ist es auch möglich, keinen eigenen Prozessor vorzusehen und den Prozessor des GSM Modems 20 zur Steuerung zu verwenden. In diesem Fall fungiert dieser Prozessor als Rechner 23. Weiters können Mikroprozessoren (µP's), Single Board Computer, wie der beschriebene JSTAMP oder native Java Prozessoren verwendet werden. Analog können auch ein µC oder ein GSM Modul mit eingebautem 64kByte Flash RAM für Benutzercode und TCP/IP stack (z.B. das µWEB GSM 10) verwendet werden.
  • Wie bereits erwähnt kann die vorgestellte Bedarfshaltestelle 1 auch dazu benutzt werden, unterschiedlichste Messwerte oder Daten zu erfassen und an einen zentralen Server 4 weiterzuleiten. In diesem allgemeineren Zusammenhang stellen der bisher behandelte Bewegungssensor, der Temperatursensor und der Taster 11 unterschiedliche Messeinrichtungen 18 dar, die von dem Rechner 23 abgefragt werden. Diese Daten werden an den zentralen Server 4 weitergeleitet, wobei die Stromversorgung mittels Solarpaneel 14 es erlaubt, das Datenerfassungsgerät unabhängig von externen Stromversorgungen zu verwenden.

Claims (7)

  1. Signalisierungsverfahren zur Signalisierung des Haltewunsches an einer Bedarfshaltestelle (1) einer Fahrtstrecke eines Transportunternehmens, vorzugsweise eines Bus-Transportunternehmens, wobei die Bedarfshaltestelle (1) nur im Falle eines gewünschten Einstieges/Ausstieges eines Fahrgastes angefahren wird, wobei der Haltewunsch über eine Bedienungseinheit (18) eingegeben wird, und ein erstes Signal (7) generiert wird, welches den Haltewunsch und eine Information über die Identität der Bedarfshaltestelle (1) beinhaltet, dieses erste Signal (7) durch ein Sendemodul (19) an zumindest einen zentralen Server (4) übertragen wird, der zentrale Server (4) jenen Bus (2) ermittelt, der die Bedarfshaltestelle (1) am ehesten zum gewünschten Haltezeitpunkt anfahren kann und den Haltewunsch an diesen Bus (2) übermittelt, indem er diesem Bus (2) ein zweites Signal (8) sendet, welches dem Busfahrer über eine Signalisierungseinrichtung (40) signalisiert wird, dadurch gekennzeichnet, dass der Busfahrer den Erhalt des Haltewunsches bestätigt und die Bestätigung an den zentralen Server (4) weitergeleitet wird.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Übermittlung des ersten und/oder des zweiten Signals über ein Mobilfunk-Protokoll, insbesondere über GSM bzw. über GPRS oder UMTS erfolgt.
  3. Verfahren nach einem der Ansprüche 1 bis 2, dadurch gekennzeichnet, dass die Ermittlung des Busses (2) durch den zentralen Server (4) automatisch erfolgt.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass der zentrale Server (4) den Bus (2) aus der Position der Bedarfshaltestelle (1) und den Fahrplan-Daten ermittelt, indem überprüft wird, welcher Bus (2) laut Fahrplan die Bedarfshaltestelle (1) am ehesten zum gewünschten Haltezeitpunkt anfahren könnte.
  5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass der zentrale Server (4) den Bus aus der Position der Bedarfshaltestelle (1) und den aktuellen Koordinaten aller bzw. mehrerer Busse (2) ermittelt, indem die Koordinaten aller Busse (2) insbesondere über GPS abgefragt werden, die die Bedarfshaltestelle (1) laut Fahrplan anfahren können und überprüft wird, welcher Bus (2) die Bedarfshaltestelle (1) am ehesten zum gewünschten Haltezeitpunkt anfahren könnte.
  6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Bestätigung, vorzugsweise mit der zu erwartenden Ankunftszeit des Busses (2) bzw. der noch verbleibenden Wartezeit, an die Bedienungseinheit (18) weitergeleitet und dort angezeigt wird.
  7. Verkehrssystem für ein Transportunternehmen, insbesondere Bus-Transportunternehmen, vorgesehen zur Durchführung des Signalisierungsverfahrens nach einem der Ansprüche 1 bis 6, umfassend zumindest eine Bedarfshaltestelle (1), welche nur im Falle eines gewünschten Einstieges/Ausstieges eines Fahrgastes angefahren wird, zumindest einen zentralen Server (4) und zumindest eine Signalisierungseinrichtung (40) in einem Fahrzeug bzw. Bus (2) des Transportunternehmens, wobei die Bedarfshaltestelle (1) eine Bedienungseinheit (18) zur Eingabe eines Haltewunsches und ein Sendemodul (19) zur Übermittlung des Haltewunsches an den zentralen Server (4) umfasst, der zentrale Server (4) ein Kommunikationsmodul zum Datenaustausch mit der Bedarfshaltestelle (1) und der Signalisierungseinrichtung (40) aufweist, wobei die Signalisierungseinrichtung (40) dazu vorgesehen ist, dass der Busfahrer damit den Erhalt des Haltewunsches bestätigt und die Bestätigung an den zentralen Server (4) weitergeleitet wird, wobei die Signalisierungseinrichtung (40) durch ein Java programmierbares Mobiltelefon realisiert ist.
EP02792577A 2002-01-09 2002-12-19 Verfahren zur signalisierung des haltewunsches an einer bedarfshaltestelle Expired - Lifetime EP1466312B1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AT02792577T ATE319153T1 (de) 2002-01-09 2002-12-19 Verfahren zur signalisierung des haltewunsches an einer bedarfshaltestelle

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
AT282002 2002-01-09
AT282002 2002-01-09
PCT/AT2002/000359 WO2003058579A1 (de) 2002-01-09 2002-12-19 Verfahren zur signalisierung des haltewunsches an einer bedarfshaltestelle

Publications (2)

Publication Number Publication Date
EP1466312A1 EP1466312A1 (de) 2004-10-13
EP1466312B1 true EP1466312B1 (de) 2006-03-01

Family

ID=3540796

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02792577A Expired - Lifetime EP1466312B1 (de) 2002-01-09 2002-12-19 Verfahren zur signalisierung des haltewunsches an einer bedarfshaltestelle

Country Status (9)

Country Link
US (1) US20050078014A1 (de)
EP (1) EP1466312B1 (de)
CN (1) CN1615498A (de)
AT (1) ATE319153T1 (de)
AU (1) AU2002358410A1 (de)
CA (1) CA2472252A1 (de)
DE (1) DE50205969D1 (de)
EA (1) EA200400920A1 (de)
WO (1) WO2003058579A1 (de)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080067227A1 (en) * 2003-06-09 2008-03-20 Poss James A Eletrically-powered programmable package deposit enclosure
US7857105B2 (en) 2003-11-17 2010-12-28 Inlink Technologies Pty Ltd System and method for forming information pertaining to a transportation device
DE602004025299D1 (de) * 2004-07-21 2010-03-11 Amri Moosa Eisa Al Pager-einrichtung und system für parkbezahlungsgebühren
CN100447829C (zh) * 2004-08-18 2008-12-31 山连根 城市停车诱导移动提示方法和实现系统
US20070024440A1 (en) * 2005-07-28 2007-02-01 Lucent Technologies Inc. School bus tracking and notification system
WO2007147673A1 (en) * 2006-06-22 2007-12-27 International Business Machines Corporation Method and system for providing information to a transportation vehicle on the presence of passengers
US20080062012A1 (en) * 2006-09-07 2008-03-13 Greg Diep Passenger pick-up bus stop notification system
TW201220237A (en) * 2010-11-02 2012-05-16 Hon Hai Prec Ind Co Ltd System and method for managing buses
SE535591C2 (sv) * 2011-02-03 2012-10-09 Scania Cv Ab Metod för bestämning av en bromsposition för en regenerativ inbromsning av ett fordon, en anordning, ett bromssystem och ett fordon
DE102014005596B4 (de) 2014-04-15 2018-10-25 Man Truck & Bus Ag Verfahren und Assistenzsystem zur Unterstützung eines Fahrgasts und/oder eines Fahrers eines öffentlichen Verkehrsmittels
CN105279953A (zh) * 2014-07-21 2016-01-27 卢祝明 一种指定站点车辆匹配搭载的互联网方法和系统
DE102017002868A1 (de) 2017-03-24 2018-09-27 Semen Schofmann System zur Benachrichtigung des Fahrers eines Wagens mit vielen Türen

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5168451A (en) * 1987-10-21 1992-12-01 Bolger John G User responsive transit system
GR920100495A (el) * 1992-11-11 1994-07-29 Panagiotis Anagnostopoulos Ενιαία ολοκληρωμένη μέ?οδος κα?οδηγήσεως, ελέγχου, πληροφορήσεως, προστασίας, επικοινωνίας και διεκπεραιώσεως διαδικασιών, κατάλληλη κυρίως για άτομα, οχήματα & κτίσματα αστικών κέντρων & εκτεταμένων περιοχών.
US6278936B1 (en) * 1993-05-18 2001-08-21 Global Research Systems, Inc. System and method for an advance notification system for monitoring and reporting proximity of a vehicle
US6006159A (en) * 1995-08-14 1999-12-21 Schmier; Kenneth J. Public transit vehicle arrival information system
US5657101A (en) * 1995-12-15 1997-08-12 Industrial Technology Research Institute LCD having a thin film capacitor with two lower capacitor electrodes and a pixel electrode serving as an upper electrode
DE19721145A1 (de) * 1997-05-21 1998-11-26 Alsthom Cge Alcatel Verfahren zur Durchführung des öffentlichen Personennahverkehrs und individueller Fahrdienst zur Durchführung des Verfahrens
AU6404799A (en) * 1998-09-30 2000-04-17 Global Research Systems, Inc. Activation system for an advance notification system for monitoring the status of vehicle travel
IES20000360A2 (en) * 1999-05-12 2001-02-07 Knack Invest Ltd A communication system
GB2378560A (en) * 2001-08-08 2003-02-12 Motorola Inc Planning and optimising a passenger journey in a mass transit system

Also Published As

Publication number Publication date
CA2472252A1 (en) 2003-07-17
EP1466312A1 (de) 2004-10-13
DE50205969D1 (de) 2006-04-27
US20050078014A1 (en) 2005-04-14
AU2002358410A1 (en) 2003-07-24
CN1615498A (zh) 2005-05-11
EA200400920A1 (ru) 2004-12-30
ATE319153T1 (de) 2006-03-15
WO2003058579A1 (de) 2003-07-17

Similar Documents

Publication Publication Date Title
DE602004002064T2 (de) System zur Unterstützung von Postlieferungen
EP1466312B1 (de) Verfahren zur signalisierung des haltewunsches an einer bedarfshaltestelle
DE60320237T2 (de) Drahtlose mobil-fahrzeug-echtzeit-verfolgungs- und benachrichtigungssysteme und diesbezügliche verfahren
EP0235498B1 (de) Einrichtung und Verfahren zur Vermittlung von Lohnfuhrwerken
DE102008058442B4 (de) Verbindungsverwaltung für eine Fahrzeugtelematikeinheit
DE60105818T2 (de) Positionsbewusste geräte
DE60104824T2 (de) System und verfahren zum automatischen liefern von statusinformationen eines fahrzeuges
DE10024007B4 (de) Verfahren zur informativen Unterstützung eines Kraftfahrzeugführers mittels eines Fahrzeug-Multimediasystems
WO2009098165A1 (de) System zur übertragung von informationen für personen im bereich eines flughafens, verfahren zur übertragung von informationen und ein personenendgerät
DE60108180T2 (de) System und verfahren zur bereitstellung einer kommunikationsverbindung
EP0184067B1 (de) Mobiles Datenterminal für Taxifahrzeuge
DE19739357B4 (de) Datenein- und Ausgabegerät für Kraftfahrzeuge sowie Verfahren zum Überwachen und Steuern von in einem Kraftfahrzeug befindlichen Funktionsmodulen
EP0155032B1 (de) Überwachungsanordnung
DE102004009121A1 (de) Fahrtroutenermittlungssystem und Ankunftsbenachrichtigungssystem für einen Reisebus
DE60102163T2 (de) System zur Verwaltung einer Vielzahl von Fahrzeugen
EP1692677B1 (de) Fahrzeugendgerät und zugehöriges logistikmanagementsystem
DE19714156C1 (de) Informationssystem mit einer Informationsbake und einem Benutzergerät
DE102017221901A1 (de) System und Verfahren zum automatischen Steuern von Einsatzfahrzeugen
DE10306011A1 (de) System zum Aufspüren eines bewegten Objektes
DE19507223A1 (de) Funkmeldesystem
EP1909243A1 (de) Einsatz-Leitsystem für mobile Sicherheitsdienste
EP0956717B1 (de) System zur telefonischen vermittlung von mobilen dienstleistungsanbietern sowie fahrzeug für dieses system
DE102004015911B4 (de) Flottensteuerung
DE60011640T2 (de) Tragbares elektronisches gerät mit einer anzeigevorrichtung und mittel zum laden von nachrichten dafür
EP1011284A2 (de) Absetzung eines Notfunkrufs mit Positionsbestimmung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040809

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO

17Q First examination report despatched

Effective date: 20041026

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SI SK TR

AX Request for extension of the european patent

Extension state: RO

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT;WARNING: LAPSES OF ITALIAN PATENTS WITH EFFECTIVE DATE BEFORE 2007 MAY HAVE OCCURRED AT ANY TIME BEFORE 2007. THE CORRECT EFFECTIVE DATE MAY BE DIFFERENT FROM THE ONE RECORDED.

Effective date: 20060301

Ref country code: IE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

Ref country code: GB

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

REF Corresponds to:

Ref document number: 50205969

Country of ref document: DE

Date of ref document: 20060427

Kind code of ref document: P

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060601

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060601

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060601

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060612

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060801

NLV1 Nl: lapsed or annulled due to failure to fulfill the requirements of art. 29p and 29m of the patents act
GBV Gb: ep patent (uk) treated as always having been void in accordance with gb section 77(7)/1977 [no translation filed]

Effective date: 20060301

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20061231

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20061231

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20061204

EN Fr: translation not filed
BERE Be: lapsed

Owner name: RAPF, KLAUS

Effective date: 20061231

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060602

Ref country code: FR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20070309

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20061219

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20060301

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CH

Payment date: 20100125

Year of fee payment: 8

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: AT

Payment date: 20100126

Year of fee payment: 8

Ref country code: DE

Payment date: 20100222

Year of fee payment: 8

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101219

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101231

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20101231

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 50205969

Country of ref document: DE

Effective date: 20110701

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20110701