EP1695295B1 - Überprüfung des geltungsbereichs von verkehrszustandsdaten - Google Patents

Überprüfung des geltungsbereichs von verkehrszustandsdaten Download PDF

Info

Publication number
EP1695295B1
EP1695295B1 EP03782465A EP03782465A EP1695295B1 EP 1695295 B1 EP1695295 B1 EP 1695295B1 EP 03782465 A EP03782465 A EP 03782465A EP 03782465 A EP03782465 A EP 03782465A EP 1695295 B1 EP1695295 B1 EP 1695295B1
Authority
EP
European Patent Office
Prior art keywords
vehicle
traffic
value
counter
traffic status
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
EP03782465A
Other languages
English (en)
French (fr)
Other versions
EP1695295A1 (de
Inventor
Martin Hauschild
Susanne Breitenberger
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.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke AG
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 Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Publication of EP1695295A1 publication Critical patent/EP1695295A1/de
Application granted granted Critical
Publication of EP1695295B1 publication Critical patent/EP1695295B1/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/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles

Definitions

  • the invention relates to a method for providing traffic condition data, a system for transmitting traffic condition data, a device in a motor vehicle for generating and transmitting traffic condition data and a computer program product for use in a motor vehicle and for generating and transmitting traffic condition data according to the preamble the relevant independent claim.
  • FCD floating car data
  • the system used consists of a GPS receiver and a GSM module. Both modules are already available in many vehicles without FCD functionality.
  • the GPS receiver measures the position and the FCD methods determine travel times of the vehicle from many of these position data. These travel times are transmitted via the GSM network as pearl necklaces (individual points of the route with location coordinates and timestamps) to the traffic data center. These can draw conclusions about the traffic situation from these travel times. In this way, data collection of traffic condition data for traffic information services is performed.
  • the data transmission over the GSM network is associated with considerable costs.
  • FCD Extended Floating Car Data
  • XFCD Extended Floating Car Data
  • XFCD uses the various existing sensors and subsystems in the vehicle, which already provide their data on central data buses in the vehicle. The evaluation of the various data during the journey can provide information on precipitation, infrastructural conditions (serpentine), local hazards, rain, slipperiness and slipping hazards and obstructions.
  • the DE-A-101 28 873 describes a system for collecting traffic telematics information with a mobile communication terminal.
  • the mobile communication terminal has a radio device.
  • the system is also provided with a position detection device and with a stationary, arranged in a motor vehicle telematics terminal.
  • the telematics terminal has a telematics communication device and has a sensor system for detecting vehicle states.
  • the position detection device is arranged in the mobile communication terminal and that only with a detected valid motor vehicle state with the aid of the telematics communication device via the radio position data to a Traffic telematics central are transmittable.
  • a method for collecting traffic data for a vehicle is known.
  • the vehicle provides position data of the vehicle to a central station, which generates traffic status messages based on a certain number of relevant data transmitted by several vehicles.
  • a central station which generates traffic status messages based on a certain number of relevant data transmitted by several vehicles.
  • the position data of the vehicle stored in previously defined, constant intervals and sent via a communication unit to the control center.
  • the control center interprets the transmitted position data of the vehicle together with the position data of other vehicles or other sources on the basis of the evaluable driving profiles.
  • the object of the invention is in particular a method for providing high quality traffic condition data at acceptable costs.
  • An essential aspect of the method according to the invention for the provision of traffic status data in the context of a traffic condition detection by a motor vehicle is that is checked in a first step, whether the motor vehicle currently participates in public road traffic, in is checked in a second step, whether the vehicle is operated differently for more than a predetermined period of time, and optionally in a third step, the traffic condition detection is interrupted.
  • the inventive check prevents in the sense of traffic jam insignificant vehicles, because they do not participate in the usual way on public roads, cause a false traffic jam message.
  • the acceptance of the use of the method according to the invention is increased due to the increasing reliability and costs for the transmission of false traffic jams from the vehicle to a corresponding the traffic situation reconstructing and performing institution, in particular a traffic data center saved.
  • the costs are, in particular, costs for corresponding SMS messages (short message service) or costs for a different transmission.
  • the inventive method allows an event-oriented generation of traffic condition data.
  • traffic status data are transmitted only if the detected traffic condition, eg a traffic jam, causes this. This significantly reduces data traffic and hence the cost of data collection without sacrificing the quality of the traffic condition data.
  • inventive method allows cost-effective, yet timely data collection for the entire road network, especially on highways, roads and on streets in city traffic.
  • the data or bus telegrams indicating these events are usually provided by the known SSI (Standard Sensor Interface) of the vehicle.
  • SSI Standard Sensor Interface
  • By the inventive selection of the above events can be reliably detected whether the vehicle currently participates in public road traffic. If a door of the vehicle is open, it can be assumed that a person has got out and stopped the vehicle for this purpose and thus no longer participates in the flowing traffic. If there is a high steering activity with large steering angles and low speed, it is assumed that the vehicle is parked. If the reverse gear is engaged, it is probably also a parking operation. Likewise, when the vehicle is moving off the road, the airbag has been deployed, or the handbrake has been applied, it can be assumed that the vehicle is not taking part in public traffic. Data from the digital map of a navigation system provides information about whether the vehicle is actually driving on a public road or is located on a large parking lot, a rest area or a petrol station, for example.
  • the count of the counter is compared with a predetermined value and, if the value falls below a predetermined first value, the traffic condition detection is suspended while retaining the previous results of the traffic condition detection.
  • the count of the counter is compared with the predetermined first value and when the first value or a further predetermined value is exceeded, the traffic condition detection is restarted by deleting the previous results of the traffic condition detection.
  • the counter reading of the counter is reset to the value "0" if the determination as to whether the vehicle is otherwise operated has been negative.
  • the traffic condition detection is continued if the determination as to whether the vehicle is operated otherwise has been negative.
  • the inventive method for data acquisition also allows an advantageous system for transmitting traffic condition data from a first vehicle to a second vehicle, in particular via an ad hoc network, or from a traffic data center to one or more motor vehicles, optionally modified, in particular via broadcast. Likewise, it enables an advantageous apparatus and computer program product for use in a motor vehicle to generate and broadcast traffic condition data.
  • Vehicle-generated data are provided by the vehicle data buses via a known standard sensor interface, preferably every second, to a computing algorithm.
  • a computing algorithm preferably every second, to a computing algorithm.
  • these are: - location coordinates from: Navigation system - Street category from: Navigation system - Distance to the next intersection from: Navigation system - Distance to the end of the traveled road segment from: Navigation system - average normal speed from: Navigation system - In-town / out-of-town (road type) from: Navigation system - speed from: vehicle bus - Steering angle from: vehicle bus - Corridor from: vehicle bus - hazard warning lights, turn signals from: vehicle bus - SECTION from: vehicle bus - DSC / ASR from: vehicle bus - Crash sensor from: vehicle bus - Airbag from: vehicle bus - Door status from: vehicle bus - Next POI type from: Navigation system - Distance POI from: Navigation system - temperature from: vehicle bus - light from: vehicle bus - Fog light from: vehicle bus -
  • POI stands for "Point of Interest", such as restaurants, gas stations, hospitals etc.
  • Data from the digital map provides information about whether the vehicle is even on a public road or z. B. located on a large park, a rest area or gas station.
  • the flow chart of the determined traffic condition scope software module 100 uses the following sequential comparisons to find indications that the vehicle is not moving in the usual way on the road.
  • the comparison 101 it is checked whether the door is open, in the comparison 102 it is checked whether a POI (Point of Interest) is in the vicinity, in the comparison 103 it is checked whether a high steering activity is present, in the comparison 104 is checked whether the reverse gear or the idling of the vehicle is engaged, in the comparison 105 is checked based on the data supplied by the navigation system (not shown), whether the vehicle is off the road, in the comparison 106, it is checked whether the handbrake on is, in the comparison 107 is checked whether the airbag has been triggered.
  • the comparison 101 it is checked whether the door is open, in the comparison 102 it is checked whether a POI (Point of Interest) is in the vicinity, in the comparison 103 it is checked whether a high steering activity is present, in the comparison 104 is checked whether the reverse gear or the idling of the vehicle is engaged, in the
  • a counter 108 is increased by "1". For example, if the door is opened, the comparison 101 gives a first "yes” and the counter is set to "1". In the next second, a new comparison 101 is made, and the counter is set to "2" with the door open, and so on. If the door is closed, the result is "No", and the next second is 102. If the result is "Yes “the counter is increased by" 1 "to” 3 ". If there is no positive comparison during a run of the comparisons 101 to 107, the count of the counter is reset to "0". Each positive comparison thus increases the count of the counter 108, but only until there is a run through the comparisons 101 to 107, in which the result of the comparisons was always “no". Possibly. the counter 101 is set to "0" as indicated at 109.
  • the value t1 in a comparison 110 is set to "60" in this embodiment. If the count of the counter 108 does not reach the count "60", the result of the comparison 110 is "No" and the detection of whether a jam exists is suspended, as indicated by "Detection PAUSE” 111. If the result of the comparison 110 is "Yes", that is, one of the states of the comparisons 101 to 107 is longer than 60 seconds, a reset of the detection as to whether or not there is a jam is performed. This is indicated by “detection RESET” 112. How the “detection RESET” is performed or what it causes will be related later FIG. 5 explained in more detail.
  • comparisons 101 to 107 can also be run in a different order. For example, query 106 could determine whether the handbrake is engaged prior to query 101, whether a door is open.
  • FIG. 2 shows the flowchart of the software module 200 to determine the expected speed level.
  • the known standard sensor interface (SSI) 201 provides the normal speed (normal speed in an undisturbed traffic flow) for some streets on the basis of a digital map (not shown) having this information. For all other roads is on the digital map, usually a DVD of the navigation system, recorded which street type 202 and which street category 203 belongs to the concrete road. If the normal speed to be expected is not available, the expected speed level for an undisturbed traffic flow is assigned according to the invention for all other roads using a table 204 with entries for the different "road types" and possibly for the different "road categories".
  • the table 204 has a lower speed threshold S1 and an upper speed threshold S2 (expected speed level) for the respective road type, wherein it is also possible to distinguish whether the vehicle is moving on-site or off-road on this road type (street category). If the vehicle is on a developed main road, the normal speed is z. B. according to the maximum speed, in particular about 100 km / h.
  • the lower speed threshold S1 is in the table at 35 km / h
  • the upper speed threshold S2 at 45 km / h is set in the table, respectively.
  • the normal speed for the concrete road can also be specified on the digital map. Possibly.
  • the lower speed threshold S1 is set at 35% of the normal speed and the upper speed threshold S2 is set at 45% of the normal speed.
  • the lower speed threshold S1 and the upper speed threshold S2 thus orient themselves at the normal speed.
  • Table 204 below gives preferred values: Street category according to SSI Inland (S1 / S2) [ km / h ] Out of town (S1 / S2) [ km / h ] 0 unspecified as previously as previously 1 highway - 46/60 2 fast road 15/25 35/45 3 regional road 15/25 30/40 4 main road 15/25 30/40 5 local road 15/25 30/40 6 connecting road 15/25 30/40 7 slow road 10/20 25/35 8 minor road 10/20 25/35 9 service road 10/20 25/35
  • the speed thresholds S1 and S2 are corresponding to a software module for determining the boundary conditions weather and road guidance FIG. 3 pass that adapts the speed thresholds to the boundary conditions if necessary.
  • FIG. 3 shows the flowchart of the software module 300 for determining the boundary conditions weather and road guidance.
  • step 302 it is compared whether the wiper of the vehicle wipes. If the result of the comparison 302 is "yes”, a value Tw1, which indicates the length of the windscreen wiper activity, is increased by the value "1" in step 303.
  • step 304 it is compared whether the current value of Tw1 is higher than a value K1 indicating a lower time threshold.
  • N1 M0 + N1.
  • N1 is a value expressing how large the influence on the normal speed of the vehicle without adverse constraints is, and thus represents a weight for the condition "wiper wipes".
  • N3 is a value that expresses how great the influence on the normal speed of the vehicle without adverse conditions is, thus setting a weight for the condition "fog or fog lamp on”.
  • N5 is a value that expresses how great the influence on the normal speed of the vehicle is without adverse conditions and thus sets a weight for the condition "dipped beam".
  • N6 is a value that expresses how great the influence on the normal speed of the vehicle without adverse conditions is and thus represents a weight for the condition "temperature lower than 4 degrees Celsius and also wiper on" is.
  • step 320 If the result of the comparison is "No" or if N6 has been added in step 319, the process continues with step 320.
  • step 320 it is checked whether the value M6 is greater than a predetermined value Mb.
  • Mb is an empirical value or is determined, for example, by test drives and indicates from which value at a lower speed due to the aforementioned boundary conditions. the normal speed is calculated. If the result of the comparison 320 is "Yes", the lower speed threshold S1 and the upper speed threshold S2 are respectively reduced from the software module 200 for determining the expected speed level by multiplication by a value P1 smaller than 1. In practice, it has been found that a value P1 of about 0.9 is suitable, i. that the S1 and S2 should be reduced to about 90% of their normal value under the conditions mentioned above.
  • FIG. 4 shows the flowchart of a software module 400 for detection of crossing areas. Delays in the flow of traffic that occur through intersections, both light-signal-controlled and non-light-signal-controlled, are recognized as such and are filtered out during normal deceleration and subsequent intersection crossing. In this way, a crossing-free driving profile is practically emulated, thus enabling condition recognition even in intersections. For this, the SSI data "distance to the next intersection" (from the navigation system with digital map) and "speed" are used. A traffic jam in front of an intersection area is in the actual traffic condition detection, Fig. 5 , identified.
  • step 404 If the result of the comparison 401 is "no", ie the vehicle is not traveling in the area of an intersection, the actual speed v of the vehicle is determined as speed v2 in step 404 to the traffic condition recognition of FIG. 5 passed.
  • FIG. 5 the flowchart of a software module 500 for detecting the traffic condition by means of a threshold method, ie to determine whether there is a congestion or free ride is given.
  • the inventive software module 500 allows the determination of a position indication for the traffic jam entrance and a position indication for the congestion exit.
  • the basic data for the threshold value process performed by the software module 500 is the data obtained from the above four software modules and the current vehicle speed data. If the software module 100 (scopes) determines that the vehicle is not participating in the traffic, the traffic condition detection becomes FIG. 5 suppressed. After participating in the traffic, the module data are used to modify the speed values v2 and to determine the current threshold values S1 and S2. The weather conditions, road conditions and road conditions (intersections, serpentines) are used to change the speed data. The modified speed data will be used for further calculations.
  • the threshold values are determined via the setpoint speed (software module 200). They divide the entire speed range into three parts; Speed v less than S1, v between S1 and S2 and v greater than S2.
  • the modified speed data is preferably assigned to one of the three areas every second.
  • the determination of the currently prevailing traffic conditions then takes place via the frequencies of the modified speed data in the individual areas.
  • Traffic light and crossing areas are already taken into account by the modification of the speed data. Traffic jams in traffic lights or crossing areas are recognized in the same way as in traffic-free areas.
  • the first step 501 of the flow chart of the software module 500 it is checked whether the speed v2 (possibly an intersection-adjusted speed of the FIG. 4 ) is less than the lower speed threshold S1 (possibly modified by the boundary conditions weather, road conditions and road guidance). If the result of the comparison 501 is "yes", which is regarded as an indication of a congestion, in step 502, starting from the count "0", it is counted up by a first counter by the value W1 (count 1 + W1). The first counter thus takes into account a low speed v2 ⁇ S1 of the vehicle. Since the flowchart is (preferably) run through every second, counting is continued every second if the comparison result remains the same.
  • the state of the counter in step 502 is compared in step 503 with a value S5 (count 1> S5).
  • step 504 If the result of the comparison 501 is "no", ie v2 is smaller than the lower speed threshold S1, it is checked in step 504 whether the (possibly modified) speed of the vehicle v2 is less than the upper speed threshold S2. If the result of the comparison 504 is "yes”, which is regarded as a clue for free travel or no congestion, in step 505, starting from the count "0", a second counter increments by the value W2 (count 2 + W2). The second counter thus takes into account a high speed v2> S2 of the vehicle. Since the flowchart is (preferably) run through every second, counting is continued every second if the comparison result remains the same.
  • the counter reading of the second counter preferably increases by the value "1" every second in step 505, ie W2 is preferably "1". Of course, another value, such as "0.5”, could also be added.
  • the state of the second counter in step 505 is compared with the value S8 in step 506. If the result is "yes”, the count of the first counter is reset to "0" in step 508. If the result is "no”, continue with step 517.
  • the first counter is then counted up in the event of congestion in step 502.
  • the count of the first counter may exceed the value S5 and the result of the comparison 503 is "Yes”.
  • the second counter is incremented in free travel in step 505 (count 2 + W2).
  • the count of the second counter may exceed the value S8 and the result of the comparison 506 is "Yes”.
  • step 513 it is checked whether the count of the second counter (count 2) has been reset to "0" for the first time in step 507. If the result is "yes”, in step 514 the location and the time at which the counter reading of the counter 1 was first greater than the value S5 in step 503 are stored (potential traffic jam entrance). Potentially because in step 509 it has yet to be shown whether there really is a traffic jam. In step 515, it is checked whether the count of the first counter (count 1) has been reset to "0" for the first time in step 508. If the result is "yes”, in step 516 the location and the time at which the counter reading of the counter 2 was first greater than the value S8 in step 506 were stored (potential congestion exit). Potentially because in step 511 it has yet to show whether there really is no traffic jam.
  • step 517 it is checked in each case whether the absolute value of the difference of counter reading 1 and counter reading 2 is greater than a value S9 (
  • the process chain shown starts again with step 501, as in the preferably one-second run.
  • step 504 If the speed v2 is between S1 and S2, the result of the comparison in step 504 is "No". This situation is considered to be undefined, ie it is not clear whether there is a traffic jam or no traffic jam.
  • step 504 ' the count of the first counter is then increased by the value W3 and the count of the second counter also by the value W3, if necessary, every second, when the pass through the in FIG. 5 the chain is shown every second.
  • W1 and W2 have the same value, W3 preferably having half the value of W1 or W2.
  • the value of W1 or W2 is "1" and the value of W3 is "0.5". It will be appreciated that another weighting may be used if this results in more reliable jam detection.
  • the count of the first counter (low speed) is compared in seconds with the value S6 in step 509 (count 1> S6). If the count of the first counter is greater than S6, if the result of the comparison is "yes”, in step 510 a first data set is generated which describes the state "congestion”. In step 518, it is checked whether there is a state change, i. whether the state "congestion" was preceded by the state "free". Each time the vehicle is restarted, the "free" state is set as the initial state.
  • the first data record and the location and time of the (previously only potential) traffic jam entrance in step 519 for the purpose of data collection to a traffic situation reconstructing and representing institution, in particular a traffic data center, preferably a regional traffic data center , preferably by SMS, transmitted.
  • step 511 it is checked whether the count of the second counter is greater than a value S7. If the result of the comparison is "yes”, a second data record is generated in step 512, which describes the state "free”. In step 520 it is checked whether there is a change of state, ie whether the state "free" was preceded by the state "congestion".
  • step 509 If the count of the first counter (traffic jam entrance) is less than or equal to S6 in step 509, the result of the comparison 509 is "no". Then, in the next step 511, it is checked whether the count of the second counter (congestion exit or free travel) is greater than or equal to S7. If the counter reading of the second counter is greater than or equal to S7, the result of the comparison is "yes" and the institution reconstructing and representing the traffic situation is preferably once again transmitted via SMS the status "free” in step 512 for the purpose of the traffic situation survey.
  • step 513 In order to be able to determine the location of the traffic jam entrance and to be able to transmit it to the traffic situation reconstructing and representing institution (not shown), after the resetting of the second counter in step 507 it is checked in step 513 whether it is the first pass or not whether this comparison 513 is performed for the first time. If the second counter has been reset to "0" for the first time in step 507, the result of the comparison 513 is "yes" and the position of the vehicle determined from the data of the navigation system at that time is stored as "congestion” in step 514. When transmitting the status "congestion” in step 510, it is also preferred to have the position of the vehicle stored in step 514, i. the "traffic jam" to the traffic situation reconstructing and performing institution preferably transmitted via SMS.
  • step 515 In order to also be able to determine the location of the congestion exit and to be able to transmit to the traffic situation reconstructing and performing institution (not shown), it is checked in step 515 after the resetting of the first counter in step 508 whether it is the first pass or whether this comparison 515 is performed for the first time. If the first counter was reset to "0" for the first time in step 508, the result of comparison 515 is "yes" and the Position of the vehicle determined by the data of the navigation system at that time is stored as "congestion exit” in step 516.
  • the position of the vehicle stored in step 516 ie the "congestion exit" to the institution reconstructing and representing the traffic situation, is preferably transmitted by SMS.
  • step 509 If the result of comparison 513 or 515 is No, or if the traffic jam entrance in step 514 or the jam exit has been stored in step 516, the comparison continues in step 509.
  • a value of about 60 seconds is selected for S5 and a value of about 180 seconds for S6 and S7. It will be appreciated that values other than these practical values may be chosen if they allow a more reliable detection of jams.

Description

  • Die Erfindung betrifft ein Verfahren zur Bereitstellung von Verkehrszustandsdaten, ein System zur Übertragung von Verkehrszustandsdaten, eine Vorrichtung in einem Kraftfahrzeug zur Generierung und Aussendung von Verkehrszustandsdaten und ein Computer-Programm-Produkt zur Verwendung in einem Kraftfahrzeug und zur Generierung und Aussendung von Verkehrszustandsdaten nach dem Oberbegriff des betreffenden unabhängigen Patentanspruchs.
  • Bekannte Fahrzeuge versenden sogenannte Floating Car Data (FCD). Das dafür eingesetzte System besteht aus einem GPS-Empfänger und einem GSM-Modul. Beide Module sind in vielen Fahrzeugen auch ohne FCD-Funktionalität bereits vorhanden. Der GPS-Empfänger misst die Position und die FCD-Verfahren ermitteln aus vielen dieser Positionsdaten Reisezeiten des Fahrzeugs. Per GSM-Netz werden diese Reisezeiten als Perlenketten (einzelne Punkte der Fahrtstrecke mit Ortskoordinaten und Zeitstempel versehen) an die Verkehrsdatenzentrale übermittelt. Diese kann aus diesen Reisezeiten Rückschlüsse auf die Verkehrslage ziehen. Auf diese Weise erfolgt eine Datenerhebung von Verkehrszustandsdaten für Verkehrsinformationsdienste.
  • Die Datenübertragung über das GSM-Netz ist mit erheblichen Kosten verbunden.
  • Um zukünftig die Verkehrslage präziser und zusätzlich mit Informationen über Wetter, Straßenzustand und lokale Gefahren zu erheben, wird FCD zu XFCD (Extended Floating Car Data) weiterentwickelt. XFCD nutzt die diversen im Fahrzeug vorhandenen Sensoren und Subsysteme, die ihre Daten schon jetzt auf zentralen Datenbussen im Fahrzeug zur Verfügung stellen. Die Auswertung der diversen Daten während der Fahrt können Aufschluss geben über Niederschläge, infrastrukturelle Gegebenheiten (Serpentinen), lokale Gefahren, Niederschläge, Glätte und Rutschgefahren und Sichtbehinderungen.
  • Die DE-A-101 28 873 beschreibt ein System zur Erfassung von Verkehrstelematik-Informationen mit einem mobilen Kommunikationsendgerät. Das mobile Kommunikationsendgerät weist eine Funkeinrichtung auf. Das System ist zudem mit einer Positionserfassungseinrichtung und mit einem stationären, in einem Kraftfahrzeug angeordneten Telematik-Endgerät versehen. Das Telematik-Endgerät weist eine Telematikkommunikationseinrichtung auf und hat eine Sensorik zur Erfassung von Kraftfahrzeugzuständen. Um ein Verkehrstelematik-System zur Verfügung zu stellen, welches mit einem mit einer Positionserfassungseinrichtung ausgestatteten mobilen Kommunikationsendgerät arbeitet, wird vorgeschlagen, dass die Positionserfassungseinrichtung im mobilen Kommunikationsendgerät angeordnet ist und dass nur bei einem erfassten gültigen Kraftfahrzeugzustand mit Hilfe der Telematikkommunikationseinrichtung über die Funkeinrichtung Positionsdaten an eine Verkehrstelematikzentrale übermittelbar sind.
  • Aus der DE-A-101 33 387 ist ein Verfahren zur Erfassung von Verkehrsdaten für ein Fahrzeug bekannt. Von dem Fahrzeug werden an eine Zentrale Positionsdaten des Fahrzeuges geliefert, die auf der Basis einer bestimmten Anzahl relevanter Daten, die von mehreren Fahrzeugen übermittelt werden, Verkehrszustandsmeldungen erarbeitet. Um das Prinzip des FCD zu realisieren, ohne dass ein auf FCD spezialisiertes Endgerät im Fahrzeug notwendig ist, wird vorgeschlagen, dass innerhalb des Fahrzeuges die Positionsdaten des Fahrzeuges in vorher definierten, konstanten Zeitabständen zwischengespeichert und über eine Kommunikationseinheit an die Zentrale gesendet werden. Anschließend werden von der Zentrale, aufgrund der daraus auswertbaren Fahrprofile, die übermittelten Positionsdaten des Fahrzeuges zusammen mit den Positionsdaten anderer Fahrzeuge oder anderer Quellen interpretiert.
  • Aufgabe der Erfindung ist insbesondere ein Verfahren zur Bereitstellung qualitativ hochwertiger Verkehrszustandsdaten bei akzeptablen Kosten.
  • Diese Aufgabe wird durch die unabhängigen Patentansprüche jeweils entsprechend ihrer Gattung gelöst. Vorteilhafte Ausgestaltungen sind Gegenstand der Unteransprüche.
  • Ein wesentlicher Aspekt des erfindungsgemäßen Verfahrens zur Bereitstellung von Verkehrszustandsdaten im Rahmen einer Verkehrszustandserkennung durch ein Kraftfahrzeug, insbesondere Verkehrszustandsdaten für die Verkehrslageerfassung, vorzugsweise Verkehrszustandsdaten zur Stauerfassung, besteht darin, dass in einem ersten Schritt überprüft wird, ob das Kraftfahrzeug aktuell am öffentlichen Straßenverkehr teilnimmt, in einem zweiten Schritt überprüft wird, ob das Fahrzeug länger als eine vorbestimmte Zeitdauer anderweitig betrieben wird, und gegebenenfalls in einem dritten Schritt die Verkehrszustandserkennung unterbrochen wird.
  • Durch die erfindungsgemäße Überprüfung wird verhindert, dass im Sinne einer Stauerfassung unbeachtliche Fahrzeuge, weil sie nicht in üblicher Weise am öffentlichen Straßenverkehr teilnehmen, eine falsche Staumeldung verursachen. Damit wird die Akzeptanz zur Nutzung des erfindungsgemäßen Verfahrens aufgrund der steigenden Zuverlässigkeit erhöht und Kosten für die Übermittlung von falschen Staumeldungen vom Fahrzeug zu einer entsprechenden die Verkehrslage rekonstruierenden und darstellenden Institution, insbesondere eine Verkehrsdatenzentrale eingespart. Bei den Kosten handelt es sich insbesondere um Kosten für entsprechende SMS-Nachrichten (Short-Message-Service) oder Kosten für eine anderweitige Übermittlung.
  • Durch dieses Verfahren, insbesondere zur Bereitstellung von Verkehrszustandsdaten zur Stauerfassung, wird es erst ermöglicht ein Verkehrsereignis weitgehend zuverlässig zu erkennen und das Verkehrsereignis nur dann als gegeben zu übermitteln, wenn es tatsächlich auftritt, d.h. das erfindungsgemäße Verfahren ermöglicht eine ereignisorientierte Generierung von Verkehrszustandsdaten. Im Unterschied zu dem bekannten Verfahren, werden Verkehrszustandsdaten nur dann übertragen, wenn der erkannte Verkehrszustand, z.B. ein Verkehrs-Stau, dies veranlasst. Damit wird der Datenverkehr und damit die Kosten der Datenerhebung erheblich gesenkt, ohne dass dies zu Lasten der Qualität der Verkehrszustandsdaten geht.
  • Vielmehr ermöglicht erst das erfindungsgemäße Verfahren eine kostengünstige und dennoch zeitnahe Datenerhebung für das gesamte Straßennetz, insbesondere auf Autobahnen, Landstrassen und auf Straßen im Stadtverkehr.
  • Alternativ oder ergänzend ist bei einer Ausführungsform der Erfindung vorgesehen, dass überprüft wird, ob eine Tür des Fahrzeugs geöffnet ist und/oder ob ein sogenannter Point of Interest in der Nähe des Fahrzeugs ist und/oder ob eine hohe Lenkaktivität des Fahrzeugs vorliegt und/oder ob der Rückwärtsgang und/oder der Leerlauf des Fahrzeugs eingelegt ist und/oder sich das Fahrzeug abseits eine Straße bewegt und/oder ob die Handbremse angezogen ist und/oder der Airbag ausgelöst ist und bei Vorliegen mindestens eines dieser Ereignisse ein Zähler bzw. Timer anläuft, der erfasst, seit wann mindestens eines dieser Ereignisse ununterbrochen vorliegt und einen entsprechenden Zählerstand bereitstellt.
  • Die Daten bzw. Bus-Telegramme, die diese Ereignisse anzeigen, werden üblicherweise vom bekannten SSI (Standard Sensor Interface) des Fahrzeugs bereitgestellt. Durch die erfindungsgemäße Auswahl der o.g. Ereignisse kann in zuverlässiger erkannt werden, ob das Fahrzeug aktuell am öffentlichen Straßenverkehr teilnimmt. Ist eine Tür des Fahrzeugs geöffnet, ist davon auszugehen, dass eine Person aussteigt und das Fahrzeug hierzu angehalten hat und damit nicht mehr am fließenden Verkehr teilnimmt. Liegt eine hohe Lenkaktivität mit großen Lenkeinschlägen und niedriger Geschwindigkeit vor, ist von einem Parkvorgang des Fahrzeugs auszugehen. Ist der Rückwärtsgang eingelegt handelt es sich vermutlich ebenfalls um einen Parkvorgang. Ebenso ist dann, wenn sich das Fahrzeug abseits einer Strasse bewegt, der Airbag ausgelöst worden ist oder die Handbremse angezogen ist, davon auszugehen, dass das Fahrzeug nicht am öffentlichen Straßenverkehr teilnimmt. Daten aus der digitalen Karte eines Navigationssystems geben Aufschluss darüber, ob das Fahrzeug überhaupt auf einer öffentlichen Straße fährt oder sich z.B. auf einem großen Parkgelände, einer Rastanlage oder einer Tankstelle befindet.
  • Um Fehlinterpretationen dieser Ereignisse zu vermeiden, ist erfindungsgemäß vorgesehen zu überprüfen, ob diese Ereignisse eine gewisse Zeitdauer ununterbrochen bestehen. Für jedes Ereignis kann eine diesem zugeordnete Zeitdauer zur Überwachung vorgesehen werden. Durch die Verwendung solcher Erfahrungswerte lässt sich die Zuverlässigkeit der Erkennung, ob das Fahrzeug aktuell am öffentlichen Verkehr teilnimmt vermutlich weiter erhöhen. Ebenso können mehrere Ereignisse miteinander durch "UND"- oder "ODER" - Operationen verknüpft werden, um zu ermitteln, ob das Fahrzeug am öffentlichen Verkehr teilnimmt.
  • Alternativ oder ergänzend ist bei einer anderen Ausführungsform der Erfindung vorgesehen, dass der Zählerstand des Zählers mit einem vorgegebenen Wert verglichen wird und bei Unterschreiten eines vorgegebenen ersten Werts die Verkehrszustandserkennung unter Beibehaltung der bisherigen Ergebnisse der Verkehrszustandserkennung ausgesetzt wird.
  • Alternativ oder ergänzend ist bei einer Ausführungsform der Erfindung vorgesehen, dass der Zählerstand des Zählers mit dem vorgegebenen ersten Wert verglichen wird und bei Überschreiten des ersten Werts oder eines weiteren vorgegebenen Werts die Verkehrszustandserkennung unter Löschung der bisherigen Ergebnisse der Verkehrszustandserkennung neu gestartet wird.
  • Diesen Maßnahmen liegt die Erkenntnis zu Grunde, dass bisherige Daten der Verkehrszustandserkennung nur dann verlässliche Aussagen über das Vorhandensein eines Staus ermöglichen, wenn sich die Situation nicht grundlegend geändert hat. Erfindungsgemäß wird dementsprechend vorgeschlagen, die bisherigen Daten der Verkehrszustandserkennung dann nicht mehr zur Ermittlung eines Staus zu verwenden, wenn zwischenzeitlich für eine längere Zeit Umstände ermittelt worden sind, die nahelegen, dass das Fahrzeug nicht mehr in üblicher Weise am Straßenverkehr teilnimmt.
  • Alternativ oder ergänzend ist bei einer Ausführungsform der Erfindung vorgesehen, dass der Zählerstand des Zählers auf den Wert "0" zurückgesetzt wird, wenn die Ermittlung, ob das Fahrzeug anderweitig betrieben wird, negativ verlaufen ist.
  • Alternativ oder ergänzend ist bei einer Ausführungsform der Erfindung vorgesehen, dass die Verkehrszustandserkennung fortgesetzt wird, wenn die Ermittlung, ob das Fahrzeug anderweitig betrieben wird, negativ verlaufen ist.
  • Durch diese erfindungsgemäßen Maßnahmen wird erreicht, dass dann, wenn es keinen Hinweis mehr darauf gibt, dass das Fahrzeug nicht am öffentlichen Straßenverkehr teilnimmt, die Verkehrszustandserkennung unverzüglich wieder aufgenommen wird.
  • Das erfindungsgemäße Verfahren zur Datengewinnung ermöglicht ferner ein vorteilhaftes System zur Übertragung von Verkehrszustandsdaten von einem ersten Fahrzeug an ein zweites Fahrzeug, insbesondere über ein Ad-hoc-Netz, oder von einer Verkehrsdatenzentrale an ein oder mehrere Kraftfahrzeuge, gegebenenfalls modifiziert, insbesondere über Broadcast. Ebenso ermöglicht es eine vorteilhafte Vorrichtung und ein Computer-Programm-Produkt zur Verwendung in einem Kraftfahrzeug zur Generierung und Aussendung von Verkehrszustandsdaten.
  • Die Erfindung wird nachfolgend anhand von Diagrammen einer Ablauf-Steuerung näher erläutert. Es zeigen:
    • Figur 1:
    das Flussdiagramm eines Software-Moduls zur Ermittlung des Geltungsbereichs des ermittelten Verkehrszustands,
    Figur 2:
    das Flussdiagramm eines Software-Moduls zur Ermittlung des zu erwartenden Geschwindigkeitsniveaus,
    Figur 3:
    das Flussdiagramm eines Software-Moduls zur Ermittlung der Randbedingungen Wetter und Straßenführung,
    Figur 4:
    das Flussdiagramm eines Software-Moduls zur Erkennung von Kreuzungsbereichen, und
    Figur 5:
    das Flussdiagramm eines Software-Moduls zur Erkennung des Verkehrszustands.
  • Fahrzeuggenerierte Daten werden von den Fahrzeugdatenbussen per bekanntem Standard Sensor Interface, bevorzugt sekündlich, einem Rechenalgorithmus zur Verfügung gestellt. Im Einzelnen sind das :
    - Ortskoordinaten aus: Navigationssystem
    - Straßenkategorie aus: Navigationssystem
    - Entfernung zur nächsten Kreuzung aus: Navigationssystem
    - Entfernung zum Ende des befahrenen
    Straßensegments aus: Navigationssystem
    - durchschnittliche Normal-Geschwindigkeit aus: Navigationssystem
    - Innerorts/Außerorts (Straßentyp) aus: Navigationssystem
    - Geschwindigkeit aus: Fahrzeug-Bus
    - Lenkwinkel aus: Fahrzeug-Bus
    - Gang aus: Fahrzeug-Bus
    - Warnblinkanlage, Blinker aus: Fahrzeug-Bus
    - ABS aus: Fahrzeug-Bus
    - DSC / ASR aus: Fahrzeug-Bus
    - Crash-Sensor aus: Fahrzeug-Bus
    - Airbag aus: Fahrzeug-Bus
    - Türenstatus aus: Fahrzeug-Bus
    - Nächster POI-Typ aus: Navigationssystem
    - Entfernung POI aus: Navigationssystem
    - Temperatur aus: Fahrzeug-Bus
    - Licht aus: Fahrzeug-Bus
    - Nebellicht aus: Fahrzeug-Bus
    - Wischereinstellung aus: Fahrzeug-Bus
    - Wischfrequenz aus: Fahrzeug-Bus
    - Handbremse aus: Fahrzeug-Bus
  • POI steht für "Point of Interest", wie Restaurants, Tankstellen, Krankenhaus etc.
  • Für die Überprüfung des Geltungsbereiches entsprechend Figur 1 wird anhand der Daten
    • Ortskoordinaten
    • Straßenkategorie
    • Innerorts/Außerorts (Straßentyp)
    • Gangwahl
    • Türenstatus
    • Nächster POI Typ
    • Entfernung nächster POI
    • Lenkeinschlag
    • Handbremse
    • Airbag
    • Crash-Sensor
    festgestellt, ob das Fahrzeug aktuell am fließenden Verkehr teilnimmt. Der Status der Fahrzeugtüren sowie die aktuelle Gangwahl geben z. B. Aufschluss darüber, ob Personen ein- oder aussteigen (Tür öffnet sich).
  • Mittels Auswertung der Lenkwinkeleinschläge im Zusammenhang mit der Geschwindigkeit können Parkvorgänge erkannt werden. Daten aus der digitalen Karte geben Aufschluss darüber, ob das Fahrzeug überhaupt auf einer öffentlichen Straße fährt oder sich z. B. auf einem großen Parkgelände, einer Rastanlage oder Tankstelle befindet.
  • Das Flussdiagramm des Software-Moduls 100 zur Ermittlung des Geltungsbereichs des ermittelten Verkehrszustands verwendet die folgenden der Reihe nach durchgeführten Vergleiche, um Anhaltspunkte zu finden, dass sich das Fahrzeug nicht in üblicher Weise im Straßenverkehr bewegt. Beim Vergleich 101 wird geprüft, ob die Tür geöffnet ist, beim Vergleich 102 wird geprüft, ob sich ein POI (Point of Interest) in der Nähe befindet, beim Vergleich 103 wird überprüft, ob eine hohe Lenkaktivität vorliegt, beim Vergleich 104 wird geprüft, ob der Rückwärtsgang oder der Leerlauf des Fahrzeugs eingelegt ist, beim Vergleich 105 wird anhand der vom Navigationssystem (nicht dargestellt) gelieferten Daten geprüft, ob sich das Fahrzeug abseits einer Strasse befindet, beim Vergleich 106 wird geprüft, ob die Handbremse angezogen ist, beim Vergleich 107 wird überprüft, ob der Airbag ausgelöst worden ist. Ist das Ergebnis einer oder mehrerer dieser Vergleiche positiv bzw. lautet die Antwort "ja" auf einen der Vergleiche 101 bis 107, wird dies als Hinweis darauf gewertet, dass sich das Fahrzeug in einer Situation bewegt oder auch steht, die bei der Erkennung eines Staus bzw. bei der Erkennung "Freie Fahrt" bzw. "Go" nicht berücksichtigt werden sollte.
  • Bei positivem Vergleich eines oder mehrerer der Vergleiche 101 bis 107, vorzugsweise findet jede Sekunde ein Vergleich statt, wird ein Zähler 108 um "1 " erhöht. Wird beispielsweise die Tür geöffnet, ergibt der Vergleich 101 ein erstes "Ja" und der Zähler wird auf "1" gesetzt. In der nächsten Sekunde erfolgt ein neuer Vergleich 101 und der Zähler wird bei geöffneter Tür auf "2" gesetzt usw. Ist die Tür geschlossen, ist das Ergebnis "Nein", und in der nächsten Sekunde erfolgt der Vergleich 102. Ist das Ergebnis "Ja" wird der Zähler um "1" auf "3" erhöht. Ist bei einem Durchlauf der Vergleiche 101 bis 107 kein positiver Vergleich erfolgt, wird der Zählerstand des Zählers zurück auf "0" gesetzt. Jeder positive Vergleich erhöht also den Zählerstand des Zählers 108, allerdings nur so lange, bis es einen Durchlauf durch die Vergleiche 101 bis 107 gibt, bei dem das Ergebnis der Vergleiche stets "Nein" war. Ggf. wird der Zähler 101 auf "0" gesetzt, wie in 109 angegeben.
  • Der Wert t1 in einem Vergleich 110 wird in diesem Ausführungsbeispiel auf "60" festgesetzt. Erreicht der Zählerstand des Zählers 108 den Zählerstand "60" nicht, so ist das Ergebnis des Vergleichs 110 "Nein" und die Erkennung, ob ein Stau vorliegt wird ausgesetzt, wie mit "Erkennung PAUSE" 111 angegeben. Ist das Ergebnis des Vergleichs 110 "Ja", d.h. liegt einer der Zustände der Vergleiche 101 bis 107 länger als 60 Sekunden vor, wird ein Reset der Erkennung, ob ein Stau vorliegt oder nicht durchgeführt. Dies ist durch "Erkennung RESET" 112 angegeben. Wie der "Erkennung RESET" durchgeführt wird bzw. was er bewirkt wird später im Zusammenhang mit Figur 5 näher erläutert. Ist das Ergebnis der Vergleiche 101 bis 107 stets "nein" gewesen gilt dies als eine Situation, in der kein Ausnahmezustand vorliegt und die Stauererkennung wird - wie nachfolgend näher beschrieben - durchgeführt. Dies ist durch "Erkennung GO" 113 angegeben.
  • Von Vorteil ist es die Vergleiche 101 bis 107 durchlaufend der Reihe nach auszuführen - anstelle einer parallelen Durchführung der Vergleiche (nicht dargestellt), weil bei mindestens einem positiven Vergleich die nachfolgenden Vergleiche nicht mehr durchgeführt werden und damit Rechenzeit bzw. Hardware-Ressourcen eingespart werden. Ebenso können die Vergleiche 101 bis 107 auch in anderer Reihenfolge durchlaufen werden. Beispielsweise könnte die Abfrage 106, ob die Handbremse angezogen ist, vor die Abfrage 101, ob eine Tür geöffnet ist, vorgenommen werden.
  • In Figur 2 zeigt das Flussdiagramm des Software-Moduls 200 zur Ermittlung des zu erwartenden Geschwindigkeitsniveaus. Das bekannte Standard-Sensor-Interface (SSI) 201 liefert für einige Straßen die Normalgeschwindigkeit (übliche Geschwindigkeit bei einem ungestörten Verkehrsfluss) anhand einer digitalen Karte (nicht dargestellt), die diese Information aufweist. Für alle anderen Straßen ist auf der digitalen Karte, üblicherweise eine DVD des Navigationssystems, verzeichnet, welchem Straßentyp 202 und welcher Straßenkategorie 203 die konkrete Straße angehört. Falls die zu erwartende Normalgeschwindigkeit nicht zur Verfügung steht, wird erfindungsgemäß für alle anderen Straßen das zu erwartende Geschwindigkeitsniveau für einen ungestörten Verkehrsfluss anhand einer Tabelle 204 mit Einträgen für die unterschiedlichen "Straßentypen" und ggf. für die unterschiedlichen "Straßenkategorien" zugeordnet.
  • Die Tabelle 204 weist für den betreffenden Straßentyp eine untere Geschwindigkeitsschwelle S1 und eine obere Geschwindigkeitsschwelle S2 (zu erwartendes Geschwindigkeitsniveau) auf, wobei ggf. auch unterschieden wird, ob sich das Fahrzeug innerorts oder außerorts auf diesem Straßentyp (Straßenkategorie) bewegt. Befindet sich das Fahrzeug auf einer ausgebauten Bundesstrasse ist die Normalgeschwindigkeit z. B. entsprechend der zulässigen Höchstgeschwindigkeit, insbesondere ca.100 km/h. Die untere Geschwindigkeitsschwelle S1 ist in der Tabelle mit 35 km/h und die obere Geschwindigkeitsschwelle S2 ist mit 45 km/h sind in der Tabelle jeweils festgesetzt. Hierbei handelt es sich um einen Erfahrungswerte, der auf der Annahme beruht, dass unter 35 km/h wohl von einer Verkehrsstörung auszugehen ist, bei einer Geschwindigkeit von 35 bis 45 km/h eine Verkehrsstörung vorliegen könnte und bei einer Geschwindigkeit von mehr als 45 km/h wohl keine Verkehrsstörung bzw. kein Stau gegeben ist. Entsprechendes ist auch für die anderen Straßentypen in der Tabelle eingetragen.
  • Die Normalgeschwindigkeit für die konkrete Strasse kann auch auf der digitalen Karte angegeben sein. Ggf. wird bevorzugt die untere Geschwindigkeitsschwelle S1 mit 35% der Normalgeschwindigkeit und die obere Geschwindigkeitsschwelle S2 mit 45% der Normalgeschwindigkeit festgesetzt. Die untere Geschwindigkeitsschwelle S1 und die obere Geschwindigkeitsschwelle S2 orientieren sich also an der Normalgeschwindigkeit.
  • Die nachfolgende Tabelle 204 gibt bevorzugte Werte an:
    Straßenkategorie gemäß SSI Innerorts (S1/S2) [km/h] Außerorts (S1/S2) [km/h]
    0 nicht spezifiziert wie vorher wie vorher
    1 highway - 46/60
    2 fast road 15/25 35/45
    3 regional road 15/25 30/40
    4 main road 15/25 30/40
    5 local road 15/25 30/40
    6 connecting road 15/25 30/40
    7 slow road 10/20 25/35
    8 minor road 10/20 25/35
    9 service road 10/20 25/35
  • Die Geschwindigkeitsschwellen S1 und S2 werden einem Software-Modul zur Ermittlung der Randbedingungen Wetter und Straßenführung entsprechend Figur 3 übergeben, das die Geschwindigkeitsschwellen ggf. an die Randbedingungen anpasst.
  • Es versteht sich, dass diese Werte Erfahrungswerte sind, die bevorzugt gewählt werden können, um die Zuverlässigkeit der Staudetektion zu optimieren. Ebenso können die Geschwindigkeitsschwellen S1 und S2 auch dann über die Tabelle ermittelt werden, wenn die Normalgeschwindigkeit auf der digitalen Karte verzeichnet ist.
  • Unter "Straßentyp" im SSI werden insbesondere unterschieden: Autobahn (freeway bzw. highway bzw. throughway), ausgebaute Bundesstrasse (highway bzw. fast road), nicht ausgebaute Bundesstrasse (fast road bzw. regional road), Hauptstrasse (main road), Hauptstrasse, die durch einen Ort führt (local road), Verbindungsstrasse (connecting road), langsame Strasse (slow road), Nebenstrasse (minor road), und Feldweg (service road). Unter "Straßenkategorie" wird im SSI zwischen "innerorts" und "außerorts" unterschieden.
  • Figur 3 zeigt das Flussdiagramm des Software-Moduls 300 zur Ermittlung der Randbedingungen Wetter und Straßenführung.
  • Die SSI-Daten:
    • Wischerschalter
    • Wischfrequenz
    • Querbeschleunigung
    • ABS
    • ASR/DSC
    • Lenkwinkel
    • Temperatur
    • Licht
    • Nebellampe
    ermöglichen die Einschätzung von Rand- und Umfeldbedingungen wie Schneefall, Regen, Glätte, oder kurvenreiche Strecken (Serpentinen). Im Falle eines erheblichen Auftretens einer dieser Randbedingungen werden die Schwellenwerte S1 und S2 für die in Figur 5 beschriebene Verkehrszustandserkennung entsprechend angepasst.
  • Im Schritt 301 wird der Wert M, ein Wert, der die Schwere der herrschenden Randbedingungen angibt, auf "0" gesetzt, d.h. der Ausgangswert für M ist M0=0. Im Sekundentakt wird die in Figur 3 dargestellte Kette durchlaufen. Im Schritt 302 wird verglichen, ob der Scheibenwischer des Fahrzeugs wischt. Ist das Ergebnis des Vergleichs 302 "ja", wird ein Wert Tw1, der die Länge der Scheibenwischer-Aktivität angibt, im Schritt 303 um den Wert "1" erhöht. Im Schritt 304 wird verglichen, ob der aktuelle Wert von Tw1 höher als ein Wert K1 ist, der eine untere Zeitschwelle angibt. Läuft der Scheibenwischer länger als die untere Zeitschwelle K1, d.h. ist das Ergebnis des Vergleichs 304 "ja", wird der Wert M0 im Schritt 305 um den Wert N1 erhöht, M1=M0+N1. N1 ist ein Wert, der ausdrückt, wie groß die Einflussnahme auf die ohne nachteilige Randbedingungen normale Geschwindigkeit des Fahrzeugs ist und stellt damit ein Gewicht für die Bedingung "Scheibenwischer wischt" dar. Nach der Addition von N1 im Schritt 305 geht es mit den nachfolgenden Schritten weiter.
  • Wischt der Scheibenwischer nicht, ergibt der Vergleich 302 ein "Nein" und der Wert Tw1 wird im Schritt 306 auf "0" gesetzt. In diesem Fall, in dem Fall, dass der Vergleich 304 mit "Nein" ausgegangen ist oder in dem Fall, dass M1=M0+N1 addiert worden ist, geht es weiter mit dem Schritt 307. War das Ergebnis "nein" im Schritt 302 wird der Wert von Tw1 auf "0" zurückgesetzt.
  • Im Schritt 307 werden die vom SSI gelieferten Daten daraufhin überprüft, ob das ASC, das DSC oder das ABS eingreift. Ggf. ist das Ergebnis des Vergleichs 307 "ja". Da die in Figur 3 dargestellte Kette sekündlich durchlaufen wird, wird der Wert Tw2 sekündlich im Schritt 308 um den Wert "1" erhöht, wenn der Eingriff weiterhin besteht. Ist der Wert von Tw2 größer als eine untere Zeitschwelle K2, ist das Ergebnis des Vergleichs 309 "ja" und zum Wert M1 aus Schritt 305 wird der Wert N2 im Schritt 310 addiert, d.h. M2=M1+N2. N2 ist ein Wert, der ausdrückt, wie groß die Einflussnahme auf die ohne nachteilige Randbedingungen normale Geschwindigkeit des Fahrzeugs ist und stellt damit ein Gewicht für die Bedingung "ASC, DSC oder ABS aktiv" dar. Ist das Ergebnis des Vergleichs 307 "Nein", wird Tw2 im Schritt 311 auf "0" gesetzt.
  • Im nächsten Schritt 312 wird überprüft, ob die Nebellampe eingeschaltet ist. Ggf. ist das Ergebnis des Vergleichs 312 "Ja" und zum Wert M2 aus dem Schritt 310 wird im Schritt 313 der Wert N3 addiert, d.h. M3=M2+N3. N3 ist ein Wert, der ausdrückt, wie groß die Einflussnahme auf die ohne nachteilige Randbedingungen normale Geschwindigkeit des Fahrzeugs ist und stellt damit ein Gewicht für die Bedingung "Nebel bzw. Nebellampe ein" dar.
  • Ist das Ergebnis des Vergleichs im Schritt 312 "Nein" gewesen oder wurde der Wert N3 im Schritt 313 addiert, wird der Schritt 314 ausgeführt. In diesem Schritt wird überprüft, ob es sich um eine kurvige Strecke handelt. Dies kann anhand der vom SSI gelieferten Daten zum Lenkwinkel und dessen zeitliche Änderung ermittelt werden. Ist das Ergebnis des Vergleichs 314 "Ja", wird zum Wert M3 im Schritt 315 der Wert N4 addiert, d.h. M4=M3+N4. Ist das Ergebnis des Vergleichs 314 "Nein" oder wurde der Schritt 315 ausgeführt, geht es weiter mit dem Schritt 316. N4 ist ein Wert, der ausdrückt, wie groß die Einflussnahme auf die ohne nachteilige Randbedingungen normale Geschwindigkeit des Fahrzeugs ist und stellt damit ein Gewicht für die Bedingung "kurvige Strecke" dar.
  • Im Schritt 316 wird überprüft. ob das Abblendlicht eingeschaltet ist. Alternativ könnte anhand eines Tageslichtsensors überprüft werden, ob es dunkel ist und das Abblendlicht eingeschaltet werden sollte. Ein solcher Sensor, der das Abblendlicht bei Dunkelheit automatisch einschaltet ist als Sonderausstattung "Fahrlichtsteuerung" bekannt. Wird festgestellt, dass das Abblendlicht eingeschaltet ist oder eingeschaltet werden sollte, weil es dunkel ist, ist das Ergebnis des Vergleichs 316 "Ja" und zum Wert M4 wird der Wert N5 im Schritt 317 addiert, d.h. M5=M4+N5. N5 ist ein Wert, der ausdrückt, wie groß die Einflussnahme auf die ohne nachteilige Randbedingungen normale Geschwindigkeit des Fahrzeugs ist und stellt damit ein Gewicht für die Bedingung "Dunkelheit bzw. Abblendlicht ein" dar.
  • Ist das Ergebnis des Vergleichs "Nein" bzw. wurde N5 im Schritt 317 addiert, geht es weiter mit Schritt 318. Im Schritt 318 wird überprüft, ob die Temperatur niedriger als 4 Grad Celsius ist und zudem der Scheibenwischer eingeschaltet ist. Ggf. ist das Ergebnis des Vergleichs 318 "Ja" und im Schritt 319 wird zum Wert M5 der Wert N6 addiert, d.h. M6=M5+N6. N6 ist ein Wert, der ausdrückt, wie groß die Einflussnahme auf die ohne nachteilige Randbedingungen normale Geschwindigkeit des Fahrzeugs ist und stellt damit ein Gewicht für die Bedingung "Temperatur niedriger als 4 Grad Celsius und zudem Scheibenwischer eingeschaltet" dar.
  • Ist das Ergebnis des Vergleichs "Nein" bzw. wurde N6 im Schritt 319 addiert, geht es weiter mit Schritt 320.
  • Im Schritt 320 wird überprüft, ob der Wert M6 größer als ein vorgegebener Wert Mb ist. Mb ist ein Erfahrungswert bzw. wird beispielsweise durch Versuchsfahrten ermittelt und gibt an, ab welchem Wert mit einer niedrigeren Geschwindigkeit aufgrund der genannten Randbedingungen ggü. der Normalgeschwindigkeit gerechnet wird. Ist das Ergebnis des Vergleichs 320 "Ja" wird die untere Geschwindigkeitsschwelle S1 und die obere Geschwindigkeitsschwelle S2 aus dem Software-Modul 200 zur Ermittlung des zu erwartenden Geschwindigkeitsniveaus durch eine Multiplikation mit einem Wert P1, der kleiner als 1 ist, jeweils reduziert. In der Praxis hat sich herausgestellt, dass ein Wert P1 von ca. 0,9 geeignet ist, d.h. dass die S1 und S2 bei den genannten Randbedingungen auf ca. 90% ihres Normalwerts reduziert werden sollten.
  • Im nächsten Schritt wird die in Figur 3 dargestellte Kette erneut (bevorzugt) etwa sekündlich durchlaufen, es sei denn es wird festgestellt, dass sich das Fahrzeug außerhalb des Geltungsbereichs der erfindungsgemäßen Stauerkennung (vgl. Figur 1) befindet.
  • Diese ggf. durch die genannten Randbedingungen verringerten Werte für S1 und S2 stellen die Werte für S1 und S2 in der Figur 5 dar, die das Flussdiagramm des Software-Moduls zur Erkennung des Verkehrszustands zeigt. Hierdurch wird vermieden, das widrige Randbedingungen, die zu einer Reduzierung der gefahrenen Geschwindigkeit führen, ohne das ein Stau besteht, zur vermeintlichen Erkennung eines Staus führen.
  • Ferner wird der entsprechend verringerte Wert für S1 anstelle des Werts S1 in Figur 4, die das Flussdiagramm eines Software-Moduls zur Erkennung von Kreuzungsbereichen zeigt, verwendet.
  • Figur 4 zeigt das Flussdiagramm eines Software-Moduls 400 zur Erkennung von Kreuzungsbereichen. Verzögerungen im Fahrtfluss die durch Kreuzungen, sowohl lichtsignalgesteuerte als auch nicht lichtsignalgesteuerte auftreten, werden als solche erkannt und bei normaler Verzögerung und anschließender Kreuzungsüberfahrt herausgefiltert. So wird praktisch ein kreuzungsfreies Fahrprofil emuliert und damit die Zustandserkennung auch in Kreuzungsbereichen ermöglicht. Genutzt werden dafür die SSI-Daten "Entfernung zur nächsten Kreuzung" (aus dem Navigationssystem mit digitaler Karte) und "Geschwindigkeit". Ein Stau vor einem Kreuzungsbereich wird in der eigentlichen Verkehrszustandserkennung, Fig. 5, identifiziert.
  • In einem Schritt 401 wird überprüft, ob der Abstand s des Fahrzeugs bis zur nächsten Kreuzung kleiner als ein vorgegebener Abstand S3 ist. Aufgrund von Versuchsfahrten erscheint derzeit bevorzugt ein Wert von ca. 160 m für S3 geeignet. Ist das Ergebnis des Vergleichs "Ja", wird im Schritt 402 überprüft, ob die Geschwindigkeit v des Fahrzeugs kleiner als die aktuell geltende untere Geschwindigkeitsschwelle S1 ist. Wie bereits ausgeführt, handelt es sich hierbei ggf. um den reduzierten Wert für S1 (vgl. Fig. 3). Ist das Ergebnis des Vergleichs "Ja", wird nicht die tatsächliche Geschwindigkeit v des Fahrzeugs als Geschwindigkeit v2 an die Verkehrszustandserkennung der Figur 5 weitergegeben, sondern im Schritt 403 die Durchschnittsgeschwindigkeit des Fahrzeugs während der letzten 60 Sekunden vor dem Vergleich im Schritt 402, d.h. v2 = v (t-60). Diese Durchschnittsgeschwindigkeit v2 ist also eine kreuzungsbereinigte (modifizierte) Geschwindigkeit.
  • Ist das Ergebnis des Vergleichs 401 "Nein", d.h. das Fahrzeug fährt nicht im Bereich einer Kreuzung, wird die tatsächliche Geschwindigkeit v des Fahrzeugs als Geschwindigkeit v2 im Schritt 404 an die Verkehrszustandserkennung der Figur 5 weitergegeben.
  • Im nächsten Schritt wird die in Figur 4 dargestellte Kette erneut (bevorzugt) etwa sekündlich durchlaufen, es sei denn es wird festgestellt, dass sich das Fahrzeug außerhalb des Geltungsbereichs der erfindungsgemäßen Stauerkennung (vgl. Figur 1) befindet.
  • Figur 5 zeigt schließlich das Flussdiagramm eines Software-Moduls 500 zur Erkennung des Verkehrszustands mittels eines Schwellenwertverfahrens, d.h. zur Ermittlung, ob ein Stau vorliegt oder freie Fahrt gegeben ist. Zudem erlaubt das erfindungsgemäße Software-Modul 500 die Ermittlung einer Positionsangabe für die Staueinfahrt und einer Positionsangabe für die Stauausfahrt.
  • Im Anschluss an die Schritte 111 (Erkennung PAUSE), 112 (Erkennung RESET) oder 113 (Erkennung GO) wird überprüft, ob "Erkennung PAUSE" vorliegt. Ist das Ergebnis "nein" werden die in Figur 5 dargestellten Verfahrensschritte ohne eine Veränderung der Zählerstände der nachfolgend beschriebenen Zähler durchlaufen. Ist das Ergebnis "ja", wird überprüft, ob auch "Erkennung RESET" vorliegt. Liegt "Erkennung RESET" vor, d.h. ist das Ergebnis dieses Vergleichs "ja", werden die Zählerstände der nachfolgend beschriebenen zwei Zähler jeweils auf den Zählerstand "0" zurückgesetzt und die Verfahrensschritte der Figur 5 werden dann mit den Zählerständen "0" fortgesetzt. Liegt kein "Erkennung RESET" vor, werden die Verfahrensschritte der Figur 5 nach der Pause (Erkennung PAUSE) mit den zu diesem Zeitpunkt gegebenen Zählerständen fortgesetzt.
  • Zusammenfassend sind die Basisdaten für das vom Software-Modul 500 ausgeführte Schwellenwertverfahren die aus den obigen vier Software-Modulen ermittelten Daten und die aktuellen Geschwindigkeitsdaten des Fahrzeugs. Falls das Software-Modul 100 (Geltungsbereiche) ermittelt, dass das Fahrzeug nicht am fließenden Verkehr teilnimmt, wird die Verkehrzustandserkennung gemäß Figur 5 unterdrückt. Nach festgestellter Teilnahme am Verkehr werden die Moduldaten zur Modifikation der Geschwindigkeitswerte v2 und zur Bestimmung der aktuellen Schwellenwerte S1 und S2 genutzt. Über die ermittelten Randbedingungen Wetter, Straßenzustand und Straßenführung (Kreuzungen, Serpentinen) werden die Geschwindigkeitsdaten verändert. Die modifizierten Geschwindigkeitsdaten werden für die weiteren Berechnungen verwendet. Die Schwellenwerte werden über die Soll-Geschwindigkeit (Software-Modul 200) bestimmt. Sie teilen den gesamten Geschwindigkeitsbereich in drei Teile ein; Geschwindigkeit v kleiner als S1, v zwischen S1 und S2 und v größer als S2. Die modifizierten Geschwindigkeitsdaten werden bevorzugt sekündlich einem der drei Bereiche zugeordnet. Die Bestimmung der aktuell herrschenden Verkehrszustände geschieht dann über die Häufigkeiten der modifizierten Geschwindigkeitsdaten in den einzelnen Bereichen. Ampel- und Kreuzungsbereiche sind durch die Modifizierung der Geschwindigkeitsdaten bereits berücksichtigt. Staus in Ampel- oder Kreuzungsbereichen werden genauso erkannt wie in kreuzungsfreien Bereichen.
  • Im ersten Schritt 501 des Flussdiagramms des Software-Moduls 500 wird überprüft, ob die Geschwindigkeit v2 (ggf. eine kreuzungsbereinigte Geschwindigkeit der Figur 4) kleiner als die untere Geschwindigkeitsschwelle S1 ist (ggf. durch die Randbedingungen Wetter, Straßenzustand und Straßenführung modifiziert). Ist das Ergebnis des Vergleichs 501 "ja", was als Anhaltspunkt für einen Stau gilt, wird im Schritt 502, ausgehend vom Zählerstand "0", durch einen ersten Zähler um den Wert W1 hochgezählt (Zählerstand 1 + W1). Der erste Zähler berücksichtigt also eine niedrige Geschwindigkeit v2<S1 des Fahrzeugs. Da das Flussdiagramm (bevorzugt) sekündlich durchlaufen wird, wird bei gleichbleibendem Vergleichsergebnis sekündlich hochgezählt. Bevorzugt erhöht sich ggf. der Zählerstand im Schritt 502 sekündlich um den Wert "1", d.h. bevorzugt ist W1=1. Selbstverständlich könnte auch ein anderer Wert, wie "0,5", addiert werden. Der Stand des Zählers im Schritt 502 wird im Schritt 503 mit einem Wert S5 verglichen (Zählerstand 1 > S5).
  • Ist das Ergebnis des Vergleichs 501 "Nein", d.h. ist v2 kleiner als die untere Geschwindigkeitsschwelle S1, wird im Schritt 504 überprüft, ob die (ggf. modifizierte) Geschwindigkeit des Fahrzeugs v2 kleiner als die obere Geschwindigkeitsschwelle S2 ist. Ist das Ergebnis des Vergleichs 504 "Ja", was als Anhaltspunkt für freie Fahrt bzw. kein Stau gilt, wird im Schritt 505 ausgehend vom Zählerstand "0" durch einen zweiten Zähler um den Wert W2 hochgezählt (Zählerstand 2 + W2). Der zweite Zähler berücksichtigt also eine hohe Geschwindigkeit v2>S2 des Fahrzeugs. Da das Flussdiagramm (bevorzugt) sekündlich durchlaufen wird, wird bei gleichbleibendem Vergleichsergebnis sekündlich hochgezählt. Bevorzugt erhöht sich ggf. der Zählerstand des zweiten Zählers im Schritt 505 sekündlich um den Wert "1", d.h. W2 ist bevorzugt "1". Selbstverständlich könnte auch ein anderer Wert, wie "0,5", addiert werden. Der Stand des zweiten Zählers im Schritt 505 wird im Schritt 506 mit dem Wert S8 verglichen. Ist das Ergebnis "ja", wird der Zählerstand des ersten Zählers im Schritt 508 auf "0" zurückgesetzt. Ist das Ergebnis "nein", geht es mit Schritt 517 weiter.
  • Ausgehend vom Vergleich 501 wird also bei Stau im Schritt 502 der erste Zähler hochgezählt. Der Zählerstand des ersten Zählers überschreitet ggf. den Wert S5 und das Ergebnis des Vergleichs 503 ist "Ja". Dann wird im Schritt 507 der zweite Zähler, der zählt, wie viele Sekunden freie Fahrt gegeben ist, auf "0" zurückgesetzt (Zählerstand 2 = 0). Ausgehend vom Vergleich 504 wird bei freier Fahrt im Schritt 505 der zweite Zähler hochgezählt (Zählerstand 2 + W2). Der Zählerstand des zweiten Zählers überschreitet ggf. den Wert S8 und das Ergebnis des Vergleichs 506 ist "Ja". Dann wird im Schritt 508 der erste Zähler, der zählt, wie viele Sekunden Stau vorliegt, auf "0" zurückgesetzt (Zählerstand 1 = 0).
  • Im Schritt 513 wird überprüft, ob der Zählerstand des zweiten Zählers (Zählerstand 2) im Schritt 507 erstmalig auf "0" zurückgesetzt worden ist. Ist das Ergebnis "ja", wird im Schritt 514 der Ort und der Zeitpunkt zu dem erstmalig der Zählerstand des Zählers 1 im Schritt 503 größer als der Wert S5 war, gespeichert (potenzielle Staueinfahrt). Potenziell deshalb, weil sich im Schritt 509 erst noch zeigen muss, ob wirklich ein Stau vorliegt. Im Schritt 515 wird überprüft, ob der Zählerstand des ersten Zählers (Zählerstand 1) im Schritt 508 erstmalig auf "0" zurückgesetzt worden ist. Ist das Ergebnis "ja" wird im Schritt 516 der Ort und der Zeitpunkt zu dem erstmalig der Zählerstand des Zählers 2 im Schritt 506 größer als der Wert S8 war, gespeichert (potenzielle Stauausfahrt). Potenziell deshalb, weil sich im Schritt 511 erst noch zeigen muss, ob wirklich kein Stau vorliegt.
  • Nach den Schritten 513, 514, 515 und 516 wird jeweils im Schritt 517 überprüft, ob der Absolutbetrag der Differenz von Zählerstand 1 und Zählerstand 2 größer als ein Wert S9 ist (|Zählerstand 1 - Zählerstand 2 |> S9). Ist das Ergebnis des Vergleichs "ja", wird der Schritt 509 ausgeführt. Ist das Ergebnis des Vergleichs "nein", wird der Schritt 509 nicht ausgeführt und die in Figur 5 dargestellte Verfahrenskette beginnt erneut mit dem Schritt 501, wie bei dem vorzugsweise sekündlichen Durchlauf.
  • Liegt die Geschwindigkeit v2 zwischen S1 und S2, ist das Ergebnis des Vergleichs im Schritt 504 "Nein". Diese Situation wird als nicht definierter Zustand betrachtet, d.h. es ist nicht klar, ob ein Stau oder kein Stau bzw. freie Fahrt vorliegt.
  • Ist der Zählerstand des ersten Zählers kleiner als S5 oder gleich S5, ist das Ergebnis des Vergleichs 503 "Nein". Im Schritt 504' wird dann der Zählerstand des ersten Zählers um den Wert W3 und der Zählerstand des zweiten Zählers ebenfalls um den Wert W3, ggf. sekündlich, erhöht, wenn der Durchlauf durch die in Figur 5 dargestellte Kette sekündlich erfolgt. Bevorzugt haben W1 und W2 den gleichen Wert, wobei W3 bevorzugt die Hälfte des Werts von W1 bzw. W2 hat. Bevorzugt ist der Wert von W1 bzw. W2 "1" und der Wert von W3 "0,5". Es versteht sich, dass auch eine andere Gewichtung verwendet werden kann, wenn dies zu einer zuverlässigeren Stauerkennung führt.
  • Der Zählerstand des ersten Zählers (niedrige Geschwindigkeit) wird im Schritt 509 sekündlich mit dem Wert S6 verglichen (Zählerstand 1 > S6). Ist der Zählerstand des ersten Zählers größer als S6, ist das Ergebnis des Vergleichs "Ja", wird im Schritt 510 ein erster Datensatz erzeugt, der den Zustand "Stau" beschreibt. Im Schritt 518 wird überprüft, ob eine Zustandsänderung vorliegt, d.h. ob dem Zustand "Stau" der Zustand "Frei" vorausging. Bei jeder Wieder-Inbetriebnahme des Fahrzeugs wird der Zustand "Frei" als Ausgangszustand festgelegt. Ist das Ergebnis des Vergleichs "ja", wird der erste Datensatz und der Ort und die Zeit der (vormals lediglich potentiellen) Staueinfahrt im Schritt 519 zum Zweck der Datenerhebung an eine die Verkehrslage rekonstruierende und darstellende Institution, insbesondere eine Verkehrsdatenzentrale, bevorzugt eine regionale Verkehrsdatenzentrale, bevorzugt per SMS, übertragen.
  • Ist der Zählerstand des ersten Zählers kleiner oder gleich ein Wert S6, ist das Ergebnis des Vergleichs "nein". Ggf. wird im Schritt 511 überprüft, ob der Zählerstand des zweiten Zählers größer als ein Wert S7 ist. Ist das Ergebnis des Vergleichs "ja", wird im Schritt 512 ein zweiter Datensatz erzeugt, der den Zustand "Frei" beschreibt. Im Schritt 520 wird überprüft, ob eine Zustandsänderung vorliegt, d.h. ob dem Zustand "Frei" der Zustand "Stau" vorausging. Ist das Ergebnis des Vergleichs "ja", wird der zweite Datensatz und der Ort und die Zeit der (vormals lediglich potentiellen) Stauausfahrt im Schritt 521 zum Zweck der Datenerhebung an eine die Verkehrslage rekonstruierende und darstellende Institution, insbesondere eine Verkehrsdatenzentrale, bevorzugt eine regionale Verkehrsdatenzentrale, bevorzugt per SMS, übertragen.
  • Ist das Ergebnis der Vergleiche in den Schritten 518 oder 520 "nein", findet keine Datenübermittlung statt. Vielmehr beginnt das in Figur 5 beschriebene Verfahren erneut mit dem Schritt 501.
  • Ist der Zählerstand des ersten Zählers (Staueinfahrt) im Schritt 509 kleiner oder gleich S6, ist das Ergebnis des Vergleichs 509 "Nein". Dann wird im nächsten Schritt 511 überprüft, ob der Zählerstand des zweiten Zählers (Stauausfahrt bzw. freie Fahrt) größer oder gleich S7 ist. Ist der Zählerstand des zweiten Zählers größer oder gleich S7, ist das Ergebnis des Vergleichs "Ja" und an die die Verkehrslage rekonstruierende und darstellende Institution wird bevorzugt wiederum per SMS der Zustand "Frei" im Schritt 512 zum Zweck der Verkehrslageerhebung übertragen.
  • Nach der Ausgabe des Zustands "Stau" oder "Frei" oder wenn der Vergleich 511 "Nein" ist, wird die in Figur 5 dargestellte Kette erneut durchlaufen.
  • Um den Ort der Staueinfahrt zu ermitteln und an die die Verkehrslage rekonstruierende und darstellende Institution übermitteln zu können (nicht dargestellt), wird im Anschluss an die Zurücksetzung des zweiten Zählers im Schritt 507 im Schritt 513 überprüft, ob es sich um den ersten Durchlauf handelt bzw. ob dieser Vergleich 513 zum ersten Mal durchgeführt wird. Wurde der zweite Zähler im Schritt 507 zum ersten Mal auf "0" zurückgesetzt ist das Ergebnis des Vergleichs 513 "Ja" und die anhand der Daten des Navigationssystems ermittelte Position des Fahrzeugs zu diesem Zeitpunkt wird als "Staueinfahrt" im Schritt 514 gespeichert. Bei der Übermittlung des Zustands "Stau" im Schritt 510 wird bevorzugt auch die im Schritt 514 gespeicherte Position des Fahrzeugs, d.h. die "Staueinfahrt" an die die Verkehrslage rekonstruierende und darstellende Institution bevorzugt per SMS übertragen.
  • Um auch den Ort der Stauausfahrt zu ermitteln und an die die Verkehrslage rekonstruierende und darstellende Institution übermitteln zu können (nicht dargestellt), wird im Anschluss an die Zurücksetzung des ersten Zählers im Schritt 508 im Schritt 515 überprüft, ob es sich um den ersten Durchlauf handelt bzw. ob dieser Vergleich 515 zum ersten Mal durchgeführt wird. Wurde der erste Zähler im Schritt 508 zum ersten Mal auf "0" zurückgesetzt, ist das Ergebnis des Vergleichs 515 "Ja" und die anhand der Daten des Navigationssystems ermittelte Position des Fahrzeugs zu diesem Zeitpunkt wird als "Stauausfahrt" im Schritt 516 gespeichert. Bei der Übermittlung des Zustands "Frei" im Schritt 512 wird bevorzugt auch die im Schritt 516 gespeicherte Position des Fahrzeugs, d.h. die "Stauausfahrt" an die die Verkehrslage rekonstruierende und darstellende Institution bevorzugt per SMS übertragen.
  • Ist das Ergebnis des Vergleichs 513 oder 515 "Nein" oder wurde die "Staueinfahrt im Schritt 514 oder die Stauausfahrt im Schritt 516 gespeichert, geht es mit dem Vergleich in Schritt 509 weiter.
  • Bevorzugt wird für S5 ein Wert von ca. 60 Sekunden und für S6 und S7 ein Wert von ca. 180 Sekunden gewählt. Es versteht sich, dass auch andere Werte als diese Praxiswerte gewählt werden können, wenn diese eine zuverlässigere Erkennung von Staus ermöglichen.

Claims (9)

  1. Verfahren zur Bereitstellung von Verkehrszustandsdaten im Rahmen einer Verkehrszustandserkennung (500) durch ein Kraftfahrzeug, insbesondere Verkehrszustandsdaten für die Verkehrslageerfassung, vorzugsweise Verkehrszustandsdaten zur Stauerfassung, dadurch gekennzeichnet, dass
    in einem ersten Schritt (101, ..., 107) überprüft wird, ob das Kraftfahrzeug aktuell am öffentlichen Straßenverkehr teilnimmt,
    in einem zweiten Schritt (110) überprüft wird, ob das Fahrzeug länger als eine vorbestimmte Zeitdauer anderweitig betrieben wird, und, falls dem so ist,
    wird in einem dritten Schritt (111, 112) die Verkehrszustandserkennung unterbrochen.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zur Ermittlung, ob das Fahrzeug anderweitig betrieben wird, überprüft wird, ob eine Tür des Fahrzeugs geöffnet ist (101) und/oder ob ein sogenannter Point of Interest in der Nähe des Fahrzeugs ist (102) und/oder ob eine hohe Lenkaktivität des Fahrzeugs vorliegt (103) und/oder ob der Rückwärtsgang und/oder der Leerlauf des Fahrzeugs eingelegt ist (104) und/oder sich das Fahrzeug abseits eine Straße bewegt (105) und/oder ob die Handbremse angezogen ist (106) und/oder der Airbag ausgelöst ist (107) und bei Vorliegen mindestens eines dieser Ereignisse ein Zähler bzw. Timer (108) anläuft, der erfasst, seit wann mindestens eines dieser Ereignisse ununterbrochen vorliegt und einen entsprechenden Zählerstand bereitstellt.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Zählerstand des Zählers (108) mit einem vorgegebenen ersten Wert verglichen wird (110) und bei Unterschreiten des vorgegebenen Werts (t1) die Verkehrszustandserkennung unter Beibehaltung der bisherigen Ergebnisse der Verkehrszustandserkennung ausgesetzt wird.
  4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass der Zählerstand des Zählers (108) mit einem vorgegebenen ersten Wert verglichen wird (110) und bei Überschreiten des vorgegebenen ersten Werts oder eines vorgegebenen zweiten Werts die Verkehrszustandserkennung unter Löschung der bisherigen Ergebnisse der Verkehrszustandserkennung neu gestartet wird.
  5. Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass der Zählerstand des Zählers (108) auf den Wert "0" zurückgesetzt wird (109), wenn die Ermittlung, ob das Fahrzeug anderweitig betrieben wird, negativ verlaufen ist.
  6. Verfahren nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, dass die Verkehrszustandserkennung fortgesetzt wird (113), wenn die Ermittlung, ob das Fahrzeug anderweitig betrieben wird, negativ verlaufen ist.
  7. System zur Übertragung von Verkehrszustandsdaten von einem ersten Fahrzeug an ein zweites Fahrzeug, insbesondere über ein Ad-hoc-Netz, oder von einer Verkehrsdatenzentrale an ein oder mehrere Kraftfahrzeuge, insbesondere über Broadcast, dadurch gekennzeichnet, dass das System Mittel enthält, die die Datengewinnung über die Verkehrszustände mit einem Verfahren nach einem der vorstehenden Verfahrensansprüche ausführen.
  8. Vorrichtung in einem Kraftfahrzeug zur Generierung und Aussendung von Verkehrszustandsdaten, dadurch gekennzeichnet, dass die Vorrichtung Mittel enthält, die Verkehrszustandsdaten mit einem Verfahren nach einem der vorstehenden Verfahrensansprüche bereitstellen.
  9. Computer-Programm-Produkt zur Verwendung in einem Kraftfahrzeug und zur Generierung und Aussendung von Verkehrszustandsdaten, dadurch gekennzeichnet, dass das Computer-Programm-Produkt ein Verfahren nach einem der vorstehenden Verfahrensansprüche ablaufen lässt.
EP03782465A 2003-12-19 2003-12-19 Überprüfung des geltungsbereichs von verkehrszustandsdaten Expired - Lifetime EP1695295B1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2003/014642 WO2005064545A1 (de) 2003-12-19 2003-12-19 Überprüfung des geltungsbereichs von verkehrszustandsdaten

Publications (2)

Publication Number Publication Date
EP1695295A1 EP1695295A1 (de) 2006-08-30
EP1695295B1 true EP1695295B1 (de) 2008-07-02

Family

ID=34717109

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03782465A Expired - Lifetime EP1695295B1 (de) 2003-12-19 2003-12-19 Überprüfung des geltungsbereichs von verkehrszustandsdaten

Country Status (4)

Country Link
US (1) US7353107B2 (de)
EP (1) EP1695295B1 (de)
DE (1) DE50310088D1 (de)
WO (1) WO2005064545A1 (de)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7590490B2 (en) * 2006-01-09 2009-09-15 Mitac International Corporation Smart detour
US7945386B2 (en) 2006-08-25 2011-05-17 Mitac International Corporation Rerouting in vehicle navigation systems
US7692655B2 (en) 2007-02-16 2010-04-06 Mitac International Corporation Apparatus and method of generating curved baseline for map labeling
US7783417B2 (en) 2007-03-09 2010-08-24 Mitac International Corporation Methods and apparatus for determining a route having an estimated minimum fuel usage for a vehicle
US7835863B2 (en) * 2007-04-18 2010-11-16 Mitac International Corporation Method and system for navigation using GPS velocity vector
US8078641B2 (en) 2007-04-25 2011-12-13 Mitac International Corporation Adjusting spatial operations based on map density
US8570190B2 (en) * 2007-09-07 2013-10-29 Led Roadway Lighting Ltd. Centralized route calculation for a multi-hop streetlight network
US7882102B2 (en) 2007-09-10 2011-02-01 Mitac International Corporation Nearest-neighbor geographic search
US8554475B2 (en) 2007-10-01 2013-10-08 Mitac International Corporation Static and dynamic contours
US8498808B2 (en) 2008-01-18 2013-07-30 Mitac International Corp. Method and apparatus for hybrid routing using breadcrumb paths
US8290703B2 (en) 2008-01-18 2012-10-16 Mitac International Corporation Method and apparatus for access point recording using a position device
US8700314B2 (en) 2008-01-18 2014-04-15 Mitac International Corporation Method and apparatus to search for local parking
US8718928B2 (en) * 2008-04-23 2014-05-06 Verizon Patent And Licensing Inc. Traffic monitoring systems and methods
US8249804B2 (en) 2008-08-20 2012-08-21 Mitac International Corporation Systems and methods for smart city search
US8219317B2 (en) 2008-09-22 2012-07-10 Mitac International Corporation Route navigation via a proximity point
US8566010B2 (en) 2010-06-23 2013-10-22 Massachusetts Institute Of Technology System and method for providing road condition and congestion monitoring using smart messages
EP2713352B1 (de) * 2012-09-28 2015-02-11 Skobbler GmbH Verfahren zur Ermittlung verkehrstechnischer Besonderheiten im Straßenverkehr
DE102013021661B4 (de) * 2013-12-19 2018-08-02 Audi Ag Kraftfahrzeug
CN104361349A (zh) * 2014-10-31 2015-02-18 重庆大学 基于车检器和收费数据融合的异常交通状态识别方法及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3079881B2 (ja) * 1993-08-10 2000-08-21 三菱自動車工業株式会社 道路交通状況推定方法および車両運転特性制御方法
DE59700886D1 (de) * 1996-02-08 2000-01-27 Mannesmann Ag Verfahren zur erfassung von verkehrslagedaten
WO1997029471A1 (de) * 1996-02-08 1997-08-14 Mannesmann Ag Verfahren und einrichtung zur erfassung von daten über die verkehrslage
DE19755875A1 (de) * 1996-12-09 1998-06-10 Mannesmann Ag Verfahren zur Übertragung von Ortsdaten und Meßdaten von einem Endgerät, insbesondere Telematikendgerät an eine Verkehrszentrale
US6650948B1 (en) * 2000-11-28 2003-11-18 Applied Generics Limited Traffic flow monitoring
DE10128873A1 (de) * 2001-06-15 2002-12-19 Volkswagen Ag Mobiles Verkehrstelematik-System
DE10133387B4 (de) * 2001-07-10 2019-01-03 Robert Bosch Gmbh Verfahren zur Erfassung von Verkehrsdaten für ein Fahrzeug, insbesondere ein Kraftfahrzeug, und Einrichtung
US6708107B2 (en) * 2002-04-02 2004-03-16 Lockheed Martin Corporation Real-time ad hoc traffic alert distribution

Also Published As

Publication number Publication date
DE50310088D1 (de) 2008-08-14
WO2005064545A1 (de) 2005-07-14
EP1695295A1 (de) 2006-08-30
US7353107B2 (en) 2008-04-01
US20070005229A1 (en) 2007-01-04

Similar Documents

Publication Publication Date Title
EP1695317B1 (de) Verkehrszustandserkennung mit einem schwellenwertverfahren
EP1695295B1 (de) Überprüfung des geltungsbereichs von verkehrszustandsdaten
DE102015100812B4 (de) Verfahren zum Verwenden von Strassenniveaubildern zum Verbessern eines Modus eines automatisierten Fahrens für ein Fahrzeug
EP0931301B1 (de) Verfahren und vorrichtung zur übermittlung von daten zur verkehrslagebeurteilung
DE102009028024A1 (de) Parkleitsystem zur Navigation eines parkplatzsuchenden Fahrzeuges zu einem freien Parkplatz
EP0879459A1 (de) Verfahren zur erfassung von verkehrslagedaten
WO2005064564A1 (de) Ermittlung des zu erwartenden geschwindigkeitsniveaus
WO2013091742A1 (de) Verfahren zur erzeugung und nutzung verkehrsrelevanter informationen durch fahrzeuge eines fahrzeugpools
EP3347737B1 (de) Verfahren zum ermitteln einer parkfläche eines strassenabschnitts
DE102007042877A1 (de) Kraftfahrzeug und System zur Vermittlung von Fahrbahneigenschaftsinformationen
DE602006000904T2 (de) System zur Detektion von Fahrzeugverkehr mittels bordeigener telematischer Kooperationsplattform basierend auf erweiterten Stichprobenfahrzeugdaten
EP2936470A1 (de) Verfahren und system zum lernen von verkehrsereignissen sowie verwendung des systems
EP2662846A1 (de) Verfahren zum Reduzieren einer Staugefahr
DE102010043673A1 (de) Navigationssystem und Navigationsverfahren mit Verkehrsbeeinträchtigungs-Erkennungsfunktion
DE102012009822A1 (de) Verfahren zur Ermittlung einer Größe zur Beschreibung eines lokalenVerkehrs
WO2013139551A1 (de) Verfahren und vorrichtung zum ermitteln eines verkehrszustandes
DE102017003566A1 (de) Verfahren zur Unterstützung eines Fahrers eines Fahrzeugs bei der Bildung einer Rettungsgasse
EP1736932B1 (de) Verfahren und Anordung zum Bestimmen eines zurückgelegten Wegs eines Fahrzeugs
EP1695314B1 (de) Erkennung von kreuzungsbereichen bei der verkehrszustandserkennung
EP1695320B1 (de) Verfahren zur bereitstellung von verkehrzustandsdaten
DE102020206128A1 (de) Verfahren zum Steuern einer flottenbasierten Zustandsüberwachung eines Straßenabschnitts eines Straßennetzes sowie zugehöriges System und Kraftfahrzeug und zugehörige Servereinrichtung
EP1262934B1 (de) Verfahren zur Verkehrslageerfassung
EP1695315B1 (de) Ermittlung des zu erwartenden geschwindigkeitsniveaus
EP3669341A1 (de) Verfahren, vorrichtung und computerlesbares speichermedium mit instruktionen zum verarbeiten von daten in einem kraftfahrzeug für einen versand an ein backend
EP1933292A2 (de) Verfahren und System zur Beeinflussung des Verkehrsflusses innerhalb eines Streckenabschnitts

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: 20060512

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20070228

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): DE FR GB

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REF Corresponds to:

Ref document number: 50310088

Country of ref document: DE

Date of ref document: 20080814

Kind code of ref document: P

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: 20090403

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 13

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 14

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 15

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

Ref country code: GB

Payment date: 20221222

Year of fee payment: 20

Ref country code: FR

Payment date: 20221219

Year of fee payment: 20

Ref country code: DE

Payment date: 20220621

Year of fee payment: 20

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230502

REG Reference to a national code

Ref country code: DE

Ref legal event code: R071

Ref document number: 50310088

Country of ref document: DE

REG Reference to a national code

Ref country code: GB

Ref legal event code: PE20

Expiry date: 20231218

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

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20231218

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

Ref country code: GB

Free format text: LAPSE BECAUSE OF EXPIRATION OF PROTECTION

Effective date: 20231218