WO2005064566A1 - Ermittlung des zu erwartenden geschwindigkeitsniveaus - Google Patents

Ermittlung des zu erwartenden geschwindigkeitsniveaus Download PDF

Info

Publication number
WO2005064566A1
WO2005064566A1 PCT/EP2004/014218 EP2004014218W WO2005064566A1 WO 2005064566 A1 WO2005064566 A1 WO 2005064566A1 EP 2004014218 W EP2004014218 W EP 2004014218W WO 2005064566 A1 WO2005064566 A1 WO 2005064566A1
Authority
WO
WIPO (PCT)
Prior art keywords
road
vehicle
traffic
speed threshold
data
Prior art date
Application number
PCT/EP2004/014218
Other languages
English (en)
French (fr)
Inventor
Susanne Breitenberger
Martin Hauschild
Original Assignee
Bayerische Motoren Werke Aktiengesellschaft
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 Aktiengesellschaft filed Critical Bayerische Motoren Werke Aktiengesellschaft
Priority to EP04803843A priority Critical patent/EP1695315B1/de
Priority to DE502004011688T priority patent/DE502004011688D1/de
Publication of WO2005064566A1 publication Critical patent/WO2005064566A1/de
Priority to US11/454,784 priority patent/US7869934B2/en

Links

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

Definitions

  • the invention relates to a method for providing traffic status data, a system for transmitting traffic status data, a device in a motor vehicle for generating and sending traffic status data and a computer program product for use in a motor vehicle and for generating and sending traffic status data according to the preamble of the independent claim concerned.
  • FCD Floating Car Data
  • the system used for this 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 procedures determine travel times of the vehicle from many of these position data. These travel times are transmitted to the traffic data center as a string of pearls (individual points along the route with location coordinates and time stamps) via the GSM network. These can draw conclusions about the traffic situation from these travel times. In this way, data on traffic condition data for traffic information services is collected.
  • FCD In order to collect the traffic situation more precisely in the future and additionally with information about weather, road conditions and local dangers, FCD will be developed into XFCD (Extended Floating Car Data).
  • XFCD uses the various sensors and subsystems available in the vehicle, which already make their data available on central data buses in the vehicle.
  • the evaluation of the various data while driving can provide information about traffic conditions, visual impairments, road conditions (road surface), infrastructural conditions (switchbacks), local dangers, precipitation, smoothness and slipping hazards.
  • the object of the invention is a method for providing high-quality traffic condition data at acceptable costs.
  • An essential aspect of the method according to the invention for providing traffic condition data in the context of a traffic condition detection by a motor vehicle, in particular traffic condition data for the traffic situation detection, preferably traffic condition data for traffic jam detection, is that in a first step the type of road on which the vehicle is moving using the device for Position detection and the digital road map is determined, in a second step the road category of the road on which the vehicle is moving is determined using the device for position detection and the digital road map, in a third step an assignment, in particular a table, is used which assigns at least a lower speed threshold and an upper speed threshold both to the relevant road type and to the relevant road category of the road traveled by the vehicle, and in one fourth step, at least the lower speed threshold and the upper speed threshold, possibly modified, are used to determine the traffic condition.
  • the costs are, in particular, costs for corresponding SMS messages (short message service) or costs for other transmission.
  • the movement or the speed of the vehicle can also be divided into more than three speed classes or speed ranges. This can be particularly useful if not only a distinction is to be made as to whether a vehicle is stuck in a traffic jam or not, but also a determination should be made as to where, on average, the traffic jam is traveling.
  • This method in particular for providing traffic condition data for the traffic situation detection in the entire road network, preferably for traffic jam detection, makes it possible to largely reliably recognize a traffic condition and to transmit the traffic condition as given only when it actually occurs, i.e. the method according to the invention enables event-oriented or status-oriented generation of traffic status data. Traffic status data is only transmitted if the recognized traffic status, e.g. a traffic jam causing this.
  • the method according to the invention only allows inexpensive and even timely data collection by the vehicle for the entire road network, in particular on motorways, country roads and on streets in city traffic.
  • the road type and the road category of the road traveled by the vehicle from the known standard sensor interface abbreviated “SSI”, using the location position of the vehicle provided in the vehicle and one of the Street type assigned to the street position and a street category assigned to the street position is provided.
  • the road types highway or "highway”, developed federal road or “fast road”, undeveloped federal road or “regional road”, main street or “main road”, main street leads through a location or "local road”, connecting road or connecting road, slow road or “slow road”, side road or “minor road”, and dirt road or "service road” when carrying out the method according to the invention ,
  • a normal speed is assigned to the determined road type, depending on the determined road category, and a lower speed threshold with approx. 35% of normal speed and an upper speed threshold with approx. 45% of normal speed is set.
  • another embodiment of the invention provides that the determined road type, depending on the determined road category, is determined from a table stored in the vehicle with empirical values, speed values for a lower and upper speed threshold.
  • the current values for the lower and upper speed threshold are fed into the vehicle from outside the vehicle, in particular from a traffic data center, and temporarily the current values are used instead of the original values.
  • the transmission of the current values for the lower and upper speed threshold for a section of the route currently or soon to be traveled is preferably carried out into the vehicle via SMS, TMC, DAB or the like.
  • the original data can be taken from a storage device in the vehicle, in particular a DVD, and only the currently deviating values are transferred to the vehicle.
  • the normal speed for the specific street can also be indicated on the digital map.
  • the lower speed threshold S1 and the upper speed threshold S2 are then based in particular on the normal speed, preferably as indicated above.
  • the method for data acquisition according to the invention also enables an advantageous system for transmitting traffic status 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. It also enables an advantageous device and a computer program product for use in a motor vehicle for the generation and transmission of traffic condition data.
  • FIG. 1 the flow diagram of a software module for determining the scope of the determined traffic condition
  • FIG. 2 the flow diagram of a software module for determining the expected speed level
  • FIG. 3 the flowchart of a software module for determining the boundary conditions of weather and road guidance
  • Figure 4 the flow diagram of a software module for the detection of intersection areas
  • Figure 5 the flow diagram of a software module for detecting the traffic condition.
  • Vehicle-generated data are made available to a computing algorithm by the vehicle data buses via a known standard sensor interface, preferably every second.
  • a computing algorithm preferably every second.
  • Navigation system Street category from: Navigation system Distance to the next intersection from: Navigation system Distance to the end of the traffic segment from: navigation system average normal speed off: navigation system urban / extra-urban (road type) off: navigation system speed off: vehicle bus steering angle off: vehicle bus gear off: vehicle bus hazard warning system, turn signal off: vehicle Bus ABS off: Vehicle bus DSC / ASR off: Vehicle bus crash sensor off: Vehicle bus airbag off: Vehicle bus Door status off: Vehicle bus Next POI type off: Navigation system Distance POI off: Navigation system temperature off: Vehicle bus light off: Vehicle bus fog light off: Vehicle bus wiper setting off: Vehicle bus wiping frequency off: Vehicle bus handbrake off: Vehicle bus
  • POI stands for "Point of Interest", such as restaurants, petrol stations, hospitals etc.
  • the data are used to coordinate the street coordinates of the inner-city / extra-urban (street type) - gear selection door status next POI type distance next POI steering angle Handbrake airbag crash sensor
  • the status of the vehicle doors and the current gear selection give e.g. B. Information about whether people get in or out (door opens).
  • Parking processes can be identified by evaluating the steering angle turns in relation to the speed.
  • Data from the digital map provide information as to whether the vehicle is actually driving on a public road or whether it is driving.
  • B. is located on a large park, a rest area or gas station.
  • the flowchart of the software module 100 for determining the scope of the determined traffic condition uses the following comparisons, which are carried out in order to find indications that the vehicle is not moving in the usual manner in road traffic.
  • comparison 101 it is checked whether the door is open, in comparison 102 it is checked whether a POI (Point of Interest) is nearby, in comparison 103 it is checked whether there is a high level of steering activity, in comparison 104 it is checked Whether the vehicle is in reverse gear or idling, in comparison 105, the data provided by the navigation system (not shown) is used to check whether the vehicle is off the road, in comparison 106 it is checked whether the handbrake is applied, in the comparison 107 it is checked whether the airbag has been deployed.
  • POI Point of Interest
  • a counter 108 is increased by “1”. If, for example, the door is opened, comparison 101 gives a first "yes” and the counter is set to “1". In the next second there is a new comparison 101 and the counter is set to "2" when the door is open, etc. If the door is closed, the result is "No” and in the next second comparison 102 takes place. If the result is "yes”, the counter is increased by "1" to "3". If there is no positive comparison during a comparison of comparisons 101 to 107, the counter reading of the counter is reset to "0". Each positive comparison thus increases the counter reading of counter 108, but only until there is a run through the comparisons 101 to 107, where the result of the comparisons was always “no". Possibly. the counter 101 is set to "0" as indicated in 109.
  • the value t1 in a comparison 110 is set to "60". If the counter reading of the counter 108 does not reach the counter reading "60", the result of the comparison 110 is "No" and the detection of whether there is a jam is suspended as indicated by "Detection PAUSE” 111. If the result of the comparison 110 is "yes”, i.e. if one of the states of the comparisons 101 to 107 is present for more than 60 seconds, the detection is reset as to whether there is a jam or not. This is indicated by “detection RESET” 112. How the “detection RESET” is carried out or what it does is explained in more detail later in connection with FIG. 5. If the result of the comparisons 101 to 107 has always been “no”, this is considered a situation in which there is no exceptional state and the traffic jam detection is carried out - as described in more detail below. This is indicated by “detection GO" 113.
  • Comparisons 101 to 107 can also be carried out in a different order. For example, query 106 as to whether the handbrake is applied could be carried out before query 101 as to whether a door is open.
  • FIG. 2 shows the flow diagram of the software module 200 for determining the speed level to be expected.
  • the well-known standard sensor interface (SSI) 201 provides the road type 202 and the road category 203 for all roads and the normal speed for some roads using a digital map (not shown) which contains this information.
  • the digital map usually a DVD of the navigation system, shows which street type 202 and which street category 203 the specific street belongs to.
  • the expected speed level in the sense of a normal speed is assigned for the streets for which the normal speed is not available using a table 204 with entries for the different “street types” and for the different “street categories”.
  • Table 204 has a lower speed threshold S1 and an upper speed threshold S2 for the relevant road type and the relevant road category. If the vehicle is on a main road, the normal speed is z. B. according to the permissible maximum speed, in particular about 100 km / h.
  • the lower speed threshold S1 is set at 35 km / h in the table and the upper speed threshold S2 is set at 45 km / h in the table.
  • This is an empirical value, which is based on the assumption that a traffic disruption is likely to occur below 35 km / h, a traffic disruption could occur at a speed of 35 to 45 km / h and at a speed of more than 45 km / h there is probably no traffic disruption or no traffic jam. The same is entered in the table for the other street categories depending on the street type.
  • the normal speed for the specific street can also be indicated on the digital map.
  • the lower speed threshold S1 is set at 35% of the normal speed and the upper speed threshold S2 at 45% of the normal speed. The lower speed threshold S1 and the upper speed threshold S2 are thus based on the normal speed.
  • the speed thresholds S1 and S2 are transferred to a software module for determining the boundary conditions weather and road routing according to FIG. 3, which adapts the speed thresholds to the boundary conditions if necessary.
  • these values are empirical values that can preferably be selected in order to optimize the reliability of the traffic jam detection.
  • the speed thresholds S1 and S2 can also be determined from the table if the normal speed is recorded on the digital map.
  • the upper and lower speed thresholds can be transmitted into the vehicle from a traffic data center depending on the current vehicle position and / or the current time and / or the current direction of travel and can be used temporarily instead of the original table values.
  • the traffic data center can only transmit deviations from the values stored in the vehicle (table, navigation map data).
  • Current temporary conditions such as daily construction sites, current displays of variable message signs or night speed restrictions (noise protection) are advantageously taken into account without having to reduce the sensitivity of the traffic jam detection.
  • FIG. 3 shows the flowchart of the software module 300 for determining the boundary conditions weather and road guidance.
  • the threshold values S1 and S2 are adapted accordingly for the traffic condition detection described in FIG. 5.
  • N1 is a value that expresses the degree of influence on the normal speed of the vehicle without adverse boundary conditions and thus represents a weight for the “wiper wiping” condition.
  • step 311 Set to "0".
  • N3 is a value which expresses how much influence is exerted on those without adverse boundary conditions normal speed of the vehicle is and therefore represents a weight for the condition "fog or fog lamp on”.
  • step 316 it is checked whether the low beam is switched on.
  • a daylight sensor could be used to check whether it is dark and the low beam should be switched on.
  • N5 is a value that expresses how great the influence on the normal speed of the vehicle without adverse boundary conditions is and therefore represents a weight for the condition “darkness or low beam on”.
  • N6 is a value that expresses the degree of influence on the normal speed of the vehicle without adverse boundary conditions and thus represents a weight for the condition “temperature lower than 4 degrees Celsius and also windshield wipers switched on”.
  • step 320 If the result of the comparison is “No” or if N6 was 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 mentioned boundary conditions compared to. 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 from the software module 200 for determining the expected speed level are each reduced by multiplication by a value P1 that is less than 1 Practice has shown that a value P1 of approx. 0.9 is suitable, ie that S1 and S2 should be reduced to approx. 90% of their normal value under the mentioned boundary conditions.
  • the chain shown in FIG. 3 is run through again (preferably) about every second, unless it is determined that the vehicle is outside the scope of the traffic jam detection system according to the invention (see FIG. 1).
  • FIG. 4 shows the flowchart of a software module 400 for the detection of intersection areas. Delays in the flow of traffic that occur as a result of intersections, both light-signal-controlled and non-light-signal-controlled, are recognized as such and are filtered out during normal deceleration and subsequent crossing. This practically emulates an intersection-free driving profile, thus enabling status detection even in intersection areas.
  • the SSI data "Distance to the next intersection” (from the navigation system with digital map) and "Speed" are used for this. A traffic jam in front of an intersection area is identified in the actual traffic condition detection, FIG. 5.
  • step 404 If the result of the comparison 401 is “No”, that is to say the vehicle is not driving in the area of an intersection, the actual speed v of the vehicle is passed on as speed v2 in step 404 to the traffic state detection system in FIG. 5.
  • the chain shown in FIG. 4 is run through again (preferably) about every second, unless it is determined that the vehicle is outside the scope of the traffic jam detection system according to the invention (see FIG. 1).
  • Figure 5 finally shows the flowchart of a software module 500 for recognizing the traffic condition by means of a threshold value method, i.e. to determine whether there is a traffic jam or whether there is free travel.
  • the software module 500 according to the invention allows the determination of a position specification for the traffic jam entry and a position specification for the traffic jam exit.
  • the basic data for the threshold value method executed by the software module 500 are the data determined from the above four software modules and the current speed data of the vehicle. If the software module 100 (areas of application) determines that the vehicle is not participating in the flowing traffic, the traffic condition detection according to FIG. 5 is suppressed. After determined participation in traffic, the module data are used to modify the speed values v2 and to determine the current threshold values S1 and S2. The speed data are changed via the determined boundary conditions of weather, road condition and road layout (intersections, switchbacks). The modified speed data are used for further calculations.
  • the thresholds are above the Target speed (software module 200) is determined. They divide the entire speed range into three parts; Velocity v less than S1, v between S1 and S2 and v greater than S2.
  • the modified speed data are preferably assigned to one of the three areas every second.
  • the currently prevailing traffic conditions are then determined via the frequencies of the modified speed data in the individual areas.
  • Traffic light and intersection areas have already been taken into account by modifying the speed data. Traffic jams in traffic light or intersection areas are recognized just as in intersection-free areas.
  • the speed v2 (possibly an intersection-adjusted speed of FIG. 4) is lower than the lower speed threshold S1 (possibly modified by the boundary conditions weather, road condition and road guidance). If the result of the comparison 501 is “yes”, which is considered a reference point for a traffic jam, in step 502, starting from the counter reading “0”, a first counter counts up by the value W1 (counter reading 1 + W1). The first counter therefore takes into account a low speed v2 ⁇ S1 of the vehicle. Since the flowchart (preferably) is run through every second, the comparison is counted up every second if the comparison result remains the same.
  • the status of the counter in step 502 is compared in step 503 with a value S5 (counter status 1> S5).
  • step 504 If the result of the comparison 501 is “No”, ie if v2 is less 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. Is the result of the comparison 504 "Yes", which is a reference point for free travel or no traffic jam, is incremented in step 505 from the counter reading "0" by a second counter by the value W2 (counter reading 2 + W2). The second counter therefore takes a high one into account Speed v2> S2 of the vehicle Since the flowchart (preferably) is run through every second, the comparison result remains the same counted up every second.
  • the counter reading of the second counter is increased 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 status of the second counter in step 505 is compared with the value S8 in step 506. If the result is "yes”, the counter status of the first counter in step 508 is reset to "0". If the result is "no", the process continues with step 51.
  • the first counter is counted up in step 502 in the event of a traffic jam.
  • the counter reading of the first counter may exceed the value S5 and the result of the comparison 503 is "Yes”.
  • the second counter is incremented in step 505 when the vehicle is moving freely (counter reading 2 + W2).
  • the counter reading 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 counter reading of the second counter (counter reading 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 in step 503 was greater than the value S5, stored (potential traffic jam entry). Potential because in step 509 it still has to be shown whether there is really a traffic jam.
  • step 515 it is checked whether the counter reading of the first counter (counter reading 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 is used for the first time 2 was greater than the value S8 in step 506 (potential traffic jam exit). Potential because in step 511 it still has to be shown whether there is really no traffic jam.
  • step 517 it is checked in step 517 whether the absolute amount of the difference between counter reading 1 and counter reading 2 is greater than a value S9 (counter reading 1 - counter reading 2 1> S9). If the result of the comparison is "yes”, step 509 is carried out. If the result of the comparison is "no”, the Step 509 has not been carried out and the process chain shown in FIG. 5 begins again with step 501, as in the preferably second run.
  • step 504 If the speed v2 lies between S1 and S2, the result of the comparison in step 504 is "No". This situation is considered an undefined state, i.e. it is not clear whether there is a traffic jam or no traffic jam or free travel.
  • step 504 ' the counter reading of the first counter is then increased by the value W3 and the counter reading of the second counter is also increased by the value W3, if necessary every second, increased if the passage through the chain shown in Figure 5 takes place every second, preferably W1 and W2 have the same value, with W3 preferably having half the value of W1 or W2. W2 "1" and the value of W3 "0.5". It goes without saying that a different weighting can also be used if this leads to more reliable jam detection.
  • the counter reading of the first counter (low speed) is compared with the value S6 every second in step 509 (counter reading 1> S6). If the counter reading of the first counter is greater than S6, if the result of the comparison is “yes”, a first data record is generated in step 510 which describes the “traffic jam” state. In step 518 it is checked whether there is a change in state, i.e. whether the "traffic jam" state was preceded by the "free” state. Each time the vehicle is started up again, the state "free” is set as the initial state.
  • the first data record and the location and time of the (previously only potential) traffic jam entry are made in step 519 for the purpose of data collection to an institution reconstructing and representing the traffic situation, in particular a traffic data center, preferably a regional traffic data center, preferably by SMS.
  • step 511 checks 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 shows the state "Free” describes. In step 520 it is checked whether there is a change in state, ie whether the state "free” was preceded by the state "traffic jam”. If the result of the comparison is "yes”, the second data record and the location and time of the (Previously only potential) traffic jam exit in step 521 for the purpose of data collection to an institution reconstructing and representing the traffic situation, in particular a traffic data center, preferably a regional traffic data center, preferably by SMS.
  • a traffic data center preferably a regional traffic data center, preferably by SMS.
  • step 501 If the result of the comparisons in steps 518 or 520 is “no”, no data transmission takes place. Rather, the method described in FIG. 5 begins again with step 501.
  • step 509 If the counter reading of the first counter (traffic jam entry) 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 counter reading of the second counter (traffic jam exit or free travel) is greater or is 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 status "free” is again preferably sent via SMS to the institution reconstructing and representing the traffic situation in step 512 for the purpose of surveying the traffic situation ,
  • step 513 In order to determine the location of the traffic jam entrance and to be able to transmit it to the institution reconstructing and representing the traffic situation (not shown), after the second counter has been reset in step 507, a check is carried out in step 513 as to whether it is the first pass or whether this comparison 513 is made for the first time.
  • the result of the comparison 513 is "yes” and the position of the vehicle determined at this point in time on the basis of the data from the navigation system is stored as "traffic jam entry" in step 514
  • the status of "traffic jam” in step 510 is preferably also transmitted to the position of the vehicle stored in step 514, ie the "traffic jam entry" to the vehicle Reconstructing and performing institution to transmit traffic situation preferably by SMS.
  • step 515 In order to also determine the location of the traffic jam exit and to be able to transmit it to the institution reconstructing and representing the traffic situation (not shown), after the reset of the first counter in step 508 it is checked in step 515 whether this is the first pass or whether this comparison 515 is carried out for the first time. If the first counter was reset to "0" for the first time in step 508, the result of the comparison 515 is "yes” and the position of the vehicle determined at this point in time on the basis of the data from the navigation system is stored as "traffic jam exit" in step 516
  • the transmission of the “free” state in step 512 also preferably means the position of the vehicle stored in step 516, ie transmit the "traffic jam exit" to the institution reconstructing and presenting the traffic situation, preferably by SMS.
  • step 509 If the result of the comparison 513 or 515 is “No” or if the “traffic jam entry in step 514 or the traffic jam exit in step 516 has been stored, the comparison in step 509 continues.
  • a value of approximately 60 seconds is preferably selected for S5 and a value of approximately 180 seconds for S6 and S7. It goes without saying that values other than these practical values can also be selected if they enable a more reliable detection of traffic jams.

Abstract

Die Erfindung betrifft insbesondere ein Verfahren zur Bereitstellung von Verkehrszustandsdaten im Rahmen einer Verkehrszustandserkennung (500) durch ein Kraftfahrzeug, insbesondere Verkehrszustandsdaten für die Verkehrslageerfassung, vorzugsweise Verkehrszustandsdaten zur Stauerfassung. Zur Bereitstellung qualitativ hochwertiger Verkehrszustandsdaten bei akzeptablen Kosten wird vorgeschlagen, dass in einem ersten Schritt der Strassentyp auf dem sich das Fahrzeug bewegt unter Verwendung der Vorrichtung zur Positionserkennung und der digitalen Strassenkarte ermittelt wird (202). In einem zweiten Schritt wird die Strassenkategorie der Strasse auf der sich das Fahrzeug bewegt unter Verwendung der Vorrichtung zur Positionserkennung und der digitalen Strassenkarte ermittelt (203). In einem dritten Schritt wird eine Zuordnung, insbesondere eine Tabelle (204), verwendet, die sowohl dem betreffenden Strassentyp als auch der betreffenden Strassenkategorie der vom Fahrzeug befahrenen Strasse mindestens eine untere Geschwindigkeitsschwelle (S1) und eine obere Geschwindigkeitsschwelle (S2), vorzugsweise auch eine Normalgeschwindigkeit, zuordnet. Schliesslich wird in einem vierten Schritt mindestens die untere Geschwindigkeitsschwelle (S1) und die obere Geschwindigkeitsschewelle (S2), ggf. modifiziert, zur Ermittlung des Verkehrszustands herangezogen.

Description

Ermittlung des zu erwartenden Geschwindigkeitsniveaus
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 Verkehrszustände, Sichtbehinderungen, Straßenzustände (Straßenoberfläche), infrastrukturelle Gegebenheiten (Serpentinen), lokale Gefahren, Niederschläge, Glätte und Rutschgefahren. 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 der Straßentyp auf dem sich das Fahrzeug bewegt unter Verwendung der Vorrichtung zur Positionserkennung und der digitalen Straßenkarte ermittelt wird, in einem zweiten Schritt die Straßenkategorie der Straße auf der sich das Fahrzeug bewegt unter Verwendung der Vorrichtung zur Positionserkennung und der digitalen Straßenkarte ermittelt wird, in einem dritten Schritt eine Zuordnung, insbesondere eine Tabelle, verwendet wird, die sowohl dem betreffenden Straßentyp als auch der betreffenden Straßenkategorie der vom Fahrzeug befahrenen Straße mindestens eine untere Geschwindigkeitsschwelle und eine obere Geschwindigkeitsschwelle zuordnet, und in einem vierten Schritt mindestens die untere Geschwindigkeitsschwelle und die obere Geschwindigkeitsschwelle, ggf. modifiziert, zur Ermittlung des Verkehrszustands herangezogen wird.
Durch diese Maßnahmen wird eine bessere Einschätzung des Verkehrsgeschehens durch unterschiedliche Geschwindigkeitsklassen ermöglicht. So ist das Unterschreiten der unteren Geschwindigkeitsschwelle ein Indiz dafür, dass sich das Fahrzeug im Stau bewegt oder steht. Eine Geschwindigkeit des Fahrzeugs, die im Bereich zwischen der unteren und der oberen Geschwindigkeitsschwelle liegt, ist ein Indiz dafür, dass sich das Fahrzeug in einem eher Undefinierten Zustand zwischen Stau und freier Fahrt bewegt. Eine Geschwindigkeit des Fahrzeugs, die höher als die obere Geschwindigkeitsschwelle ist, ist schließlich ein Indiz dafür, dass das betreffende Fahrzeug freie Fahrt hat. Durch diese Klassifizierung wird es möglich die, die genannten Zustände unterschiedlich zu gewichten und damit auch bei mehreren Zuständen, die während des Betrachtungszeitraums zur Entscheidung ob ein Stau vorliegt oder nicht, auftreten, eine weitgehend zuverlässige Stauererkennung zu ermöglichen.
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.
Es versteht sich, dass die Bewegung bzw. die Geschwindigkeit des Fahrzeugs auch in mehr als drei Geschwindigkeitsklassen bzw. Geschwindigkeitsbereiche eingeteilt werden kann. Dies kann insbesondere dann sinnvoll sein, wenn nicht nur unterschieden werden soll, ob sich ein Fahrzeug im Stau befindet oder nicht, sondern auch ermittelt werden soll, an welchen Stellen, des Staus mit welchen Geschwindigkeiten im Schnitt gefahren wird.
Durch dieses Verfahren, insbesondere zur Bereitstellung von Verkehrszustandsdaten für die Verkehrslageerfassung im gesamten Straßennetz, vorzugsweise zur Stauerfassung, ist es möglich, einen Verkehrszustand weitgehend zuverlässig zu erkennen und den Verkehrszustand nur dann als gegeben zu übermitteln, wenn es tatsächlich auftritt, d.h. das erfindungsgemäße Verfahren ermöglicht eine ereignisorientierte bzw. zustandsorientierte Generierung von Verkehrszustandsdaten. Verkehrszustandsdaten werden nur dann übertragen, wenn der erkannte Verkehrszustand, z.B. ein Verkehrs-Stau, dies veranlasst.
Der Datenverkehr zur einer die Verkehrslage rekonstruierenden und darstellenden Institution, insbesondere eine Verkehrsdatenzentrale, vorzugsweise per SMS, und die Kosten der Datenübertragung werden damit begrenzt auf das zur Verkehrslagedarstellung notwendige Minimum, ohne dass dies zu Lasten der Qualität der Verkehrlageerfassung geht.
Vielmehr erlaubt das erfindungsgemäße Verfahren erst eine kostengünstige und sogar noch zeitnahe Datenerhebung durch das Fahrzeug 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 der Straßentyp und die Straßenkategorie der vom Fahrzeug befahrenen Straße von dem bekannten Standard-Sensor-Interface, abgekürzt „SSI", unter Verwendung der von einem im Fahrzeug bereitgestellten Ortsposition des Fahrzeugs und einem der Ortsposition zugeordneten Straßentyp und einer der Ortsposition zugeordneten Straßenkategorie bereitgestellt wird.
Damit ist keine zusätzliche Hardware oder Software zur Bereitstellung dieser Daten erforderlich, was eine kostengünstige Realisierung der Erfindung fördert.
Alternativ oder ergänzend ist bei einer Ausführungsform der Erfindung vorgesehen, die Straßentypen Autobahn bzw. „highway", ausgebaute Bundesstrasse bzw. „fast road", nicht ausgebaute Bundesstrasse bzw. „regional road", Hauptstrasse bzw. „main road", Hauptstrasse, die durch einen Ort führt bzw. „local road", Verbindungsstrasse bzw. connecting road, langsame Strasse bzw. „slow road", Nebenstrasse bzw. „minor road", und Feldweg bzw. „service road" bei der Durchführung des erfindungsgemäßen Verfahrens zu berücksichtigen.
Alternativ oder ergänzend ist bei einer weiteren Ausführungsform der Erfindung vorgesehen, die Straßenkategorien „innerorts" und „außerorts" bei der Durchführung des erfindungsgemäßen Verfahrens zu berücksichtigen.
Die erfindungsgemäße Berücksichtigung der genannten Straßentypen und jedem der Straßentypen zugeordnete Straßenkategorie erlaubt eine sehr feine Einteilung des erwarteten Geschwindigkeitsniveaus bzw. der unteren und oberen Geschwindigkeitsschwellen. Letztendlich wird hierdurch erst eine weitgehend zuverlässige und dennoch flächendeckende Stauerkennung sowohl auf Autobahnen, Landstrassen, Stadtstraßen etc. ermöglicht.
Alternativ oder ergänzend ist bei einer anderen Ausführungsform der Erfindung vorgesehen, dass dem ermittelten Straßentyp, in Abhängigkeit von der ermittelten Straßenkategorie, eine Normalgeschwindigkeit zugeordnet wird und eine untere Geschwindigkeitsschwelle mit ca. 35% der Normalgeschwindigkeit und eine obere Geschwindigkeitsschwelle mit ca. 45% der Normalgeschwindigkeit festgelegt wird.
Alternativ oder ergänzend ist bei einer anderen Ausführungsform der Erfindung vorgesehen, dass dem ermittelten Straßentyp, in Abhängigkeit von der ermittelten Straßenkategorie, aus einer im Fahrzeug hinterlegten Tabelle mit Erfahrungswerten, Geschwindigkeitswerte für eine untere und obere Geschwindigkeitsschwelle festgelegt werden.
Alternativ oder ergänzend ist bei einer weiteren Ausführungsform der Erfindung vorgesehen, dass die aktuellen Werte für die untere und obere Geschwindigkeitsschwelle, insbesondere in Abhängigkeit von der aktuellen Fahrzeugposition und der Uhrzeit, von außerhalb des Fahrzeugs in das Fahrzeug, insbesondere von einer Verkehrsdatenzentrale, zugeführt und vorübergehend die aktuellen Werte anstelle der ursprünglichen Werte genutzt werden.
Die Übertragung der aktuellen Werte für die untere und obere Geschwindigkeitsschwelle für einen aktuell oder demnächst befahrenen Streckenabschnitt erfolgt bevorzugt in das Fahrzeug hinein über SMS, TMC, DAB oder dergleichen. Die ursprünglichen Daten können von einer Speichereinrichtung im Fahrzeug, insbesondere einer DVD, genommen werden und nur die aktuell abweichenden Werte werden ins Fahrzeug übertragen.
Die Normalgeschwindigkeit für die konkrete Strasse kann auch auf der digitalen Karte angegeben sein. Die untere Geschwindigkeitsschwelle S1 und die obere Geschwindigkeitsschwelle S2 orientieren sich dann insbesondere an der Normalgeschwindigkeit, vorzugsweise wie zuvor angegeben. 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 alle Straßen den Straßentyp 202 und die Straßenkategorie 203 und für einige Straßen die Normalgeschwindigkeit, anhand einer digitalen Karte (nicht dargestellt), die diese Informationen aufweist. Für alle Straßen ist auf der digitalen Karte, üblicherweise einer DVD des Navigationssystems, verzeichnet, welchem Straßentyp 202 und welcher Straßenkategorie 203 die konkrete Straße angehört. Erfindungsgemäß wird für die Straßen zu denen die Normalgeschwindigkeit nicht zur Verfügung steht, das zu erwartende Geschwindigkeitsniveau im Sinne einer Normalgeschwindigkeit anhand einer Tabelle 204 mit Einträgen für die unterschiedlichen „Straßentypen" und für die unterschiedlichen „Straßenkategorien" zugeordnet.
Die Tabelle 204 weist für den betreffenden Straßentyp und die betreffende Straßenkategorie eine untere Geschwindigkeitsschwelle S1 und eine obere Geschwindigkeitsschwelle S2 auf. 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 in der Tabelle jeweils festgesetzt. Hierbei handelt es sich um einen Erfahrungswert, 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ßenkategorien je nach Straßentyp in der Tabelle eingetragen.
Die Normalgeschwindigkeit für die konkrete Strasse kann auch auf der digitalen Karte angegeben sein. Bei einer möglichen Ausführungsform wird 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 Erfahrungswerte an:
Figure imgf000013_0001
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.
Ergänzend dazu können die obere und untere Geschwindigkeitsschwelle in Abhängigkeit von der aktuellen Fahrzeugposition und/oder der aktuellen Uhrzeit und/oder der aktuellen Fahrtrichtung von einer Verkehrsdatenzentrale in das Fahrzeug hinein übertragen werden und statt den ursprünglichen Tabellenwerten temporär genutzt werden. Um das zu übertragende Datenaufkommen klein zu halten, kann die Verkehrsdatenzentrale auch nur Abweichungen zu den im Fahrzeug hinterlegten Werten (Tabelle, Navigationskartendaten) übermitteln. Aktuelle temporäre Gegebenheiten wie z.B. Tagesbaustellen, aktuelle Anzeigen von Wechselverkehrszeichen oder nächtliche Geschwindigkeitsbeschränkungen (Lärmschutz) werden vorteilhafterweise berücksichtigt, ohne dabei die Empfindlichkeit der Stauerkennung verringern zu müssen.
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 MO 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' SI (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. I
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 51 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 1 > 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 Zustande „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

Patentansprüche
1. Verfahren zur Bereitstellung von Verkehrszustandsdaten im Rahmen einer Verkehrszustandserkennung (500) durch ein Kraftfahrzeug, insbesondere Verkehrszustandsdaten für die Verkehrslageerfassung, vorzugsweise Verkehrszustandsdaten zur Stauerfassung, und das Kraftfahrzeug eine Vorrichtung zur Positionserkennung unter Verwendung einer auf einem - Datenträger gespeicherten digitalen Straßenkarte, insbesondere ein GPS- Navigationssystem mit einer DVD als digitale Straßenkarte, dadurch gekennzeichnet, dass in einem ersten Schritt der Sträßentyp auf dem sich das Fahrzeug bewegt unter Verwendung der Vorrichtung zur Positionserkennung und der digitalen Straßenkarte ermittelt wird (202), in einem zweiten Schritt die Straßenkategorie der Straße auf der sich das Fahrzeug bewegt unter Verwendung der Vorrichtung zur Positionserkennung und der digitalen Straßenkarte ermittelt wird (203), in einem dritten Schritt eine Zuordnung, insbesondere eine Tabelle (204), verwendet wird, die sowohl dem betreffenden Straßentyp als auch der betreffenden Straßenkategorie der vom Fahrzeug befahrenen Straße mindestens eine untere Geschwindigkeitsschwelle (S1) und eine obere Geschwindigkeitsschwelle (S2), vorzugsweise auch eine Normalgeschwindigkeit, zuordnet, und in einem vierten Schritt mindestens die untere Geschwindigkeitsschwelle (S1) und die obere Geschwindigkeitsschwelle (S2), ggf. modifiziert, zur Ermittlung des Verkehrszustands herangezogen wird.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass aktuelle Werte oder demnächst aktuelle Werte für die untere und obere Geschwindigkeitsschwelle (S1 , S2), insbesondere in Abhängigkeit von der aktuellen Fahrzeugposition und der Uhrzeit, von außerhalb des Fahrzeugs in das Fahrzeug, insbesondere von einer Verkehrsdatenzentrale, übertragen und vorübergehend die aktuellen Werte anstelle der ursprünglichen Werte genutzt werden.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Übertragung der aktuellen Werte für die untere und obere Geschwindigkeitsschwelle (S1 , S2) für einen aktuell oder demnächst befahrenen Streckenabschnitt in das Fahrzeug hinein über Funk, insbesondere Mobilfunk, Rundfunk, wie SMS, TMC, DAB, DVB-T, GPRS, UMTS, Satelliten-Broadcast oder dergleichen erfolgt.
4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die ursprünglichen Werte bevorzugt von einer Speichereinrichtung im Fahrzeug, insbesondere einer DVD, genommen werden und nur die aktuell abweichenden oder demnächst abweichenden Werte ins Fahrzeug übertragen werden.
5. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass der Straßentyp und die Straßenkategorie, sowie vorzugsweise auch die Normal-Geschwindigkeit sofern verfügbar, der vom Fahrzeug befahrenen Straße vom Standard-Sensor-Interface, auch SSI genannt, bereitgestellt wird.
6. Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch die Straßentypen Autobahn bzw. „highway", ausgebaute Bundesstrasse bzw. „fast road", nicht ausgebaute Bundesstrasse bzw. „regional road", Hauptstrasse bzw. „main road", Hauptstrasse, die durch einen Ort führt bzw. „local road", Verbindungsstrasse bzw. connecting road, langsame Strasse bzw. „slow road", Nebenstrasse bzw. „minor road", und Feldweg bzw. „service road".
7. Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch die Straßenkategorien „innerorts" und „außerorts".
Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass dem ermittelten Straßentyp, in Abhängigkeit von der ermittelten Straßenkategorie, eine Normalgeschwindigkeit zugeordnet wird und die untere Geschwindigkeitsschwelle (S1 ) mit ca. 35% der Normalgeschwindigkeit und die obere Geschwindigkeitsschwelle (S2) mit ca. 45% der Normalgeschwindigkeit festgelegt wird.
9. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Normalgeschwindigkeit der Straße an ihrer befahrenen Position von der Vorrichtung zur Positionserkennung unter Verwendung einer auf einem Datenträger gespeicherten digitalen Straßenkarte bereitgestellt wird und die untere Geschwindigkeitsschwelle (S1) mit ca. 35% der Normalgeschwindigkeit und die obere Geschwindigkeitsschwelle (S2) mit ca. 45% der Normalgeschwindigkeit festgelegt wird.
10. 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, dadurch gekennzeichnet, dass die Datengewinnung über die Verkehrszustände mit einem Verfahren nach einem der vorstehenden Verfahrensansprüche erfolgt.
11. Vorrichtung in einem Kraftfahrzeug zur Generierung und Aussendung von Verkehrszustandsdaten, dadurch gekennzeichnet, dass die Vorrichtung ein Verfahren nach einem der vorstehenden Verfahrensansprüche ausführt.
12. 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.
PCT/EP2004/014218 2003-12-19 2004-12-14 Ermittlung des zu erwartenden geschwindigkeitsniveaus WO2005064566A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP04803843A EP1695315B1 (de) 2003-12-19 2004-12-14 Ermittlung des zu erwartenden geschwindigkeitsniveaus
DE502004011688T DE502004011688D1 (de) 2003-12-19 2004-12-14 Ermittlung des zu erwartenden geschwindigkeitsniveaus
US11/454,784 US7869934B2 (en) 2003-12-19 2006-06-19 Determination of an expected speed level

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
PCT/EP2003/014643 WO2005064564A1 (de) 2003-12-19 2003-12-19 Ermittlung des zu erwartenden geschwindigkeitsniveaus
EPPCT/EP03/14643 2003-12-19

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/454,784 Continuation US7869934B2 (en) 2003-12-19 2006-06-19 Determination of an expected speed level

Publications (1)

Publication Number Publication Date
WO2005064566A1 true WO2005064566A1 (de) 2005-07-14

Family

ID=34717110

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/EP2003/014643 WO2005064564A1 (de) 2003-12-19 2003-12-19 Ermittlung des zu erwartenden geschwindigkeitsniveaus
PCT/EP2004/014218 WO2005064566A1 (de) 2003-12-19 2004-12-14 Ermittlung des zu erwartenden geschwindigkeitsniveaus

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/EP2003/014643 WO2005064564A1 (de) 2003-12-19 2003-12-19 Ermittlung des zu erwartenden geschwindigkeitsniveaus

Country Status (3)

Country Link
US (1) US7869934B2 (de)
DE (1) DE502004011688D1 (de)
WO (2) WO2005064564A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1947623A1 (de) * 2007-01-17 2008-07-23 Audi Ag Verfahren und Vorrichtung zur dynamischen Klassifikation von Objekten und/oder Verkehrssituationen
DE102007062680B4 (de) * 2006-12-28 2013-05-23 Denso Corporation Verkehrsstaugradbestimmungsvorrichtung, Verkehrsstaugradmeldevorrichtung und Programm

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8606516B2 (en) * 2004-11-30 2013-12-10 Dash Navigation, Inc. User interface system and method for a vehicle navigation device
JP4938591B2 (ja) * 2007-08-22 2012-05-23 トヨタ自動車株式会社 交通情報作成方法、交通情報作成装置及びナビゲーションシステム
US20090287405A1 (en) * 2008-05-15 2009-11-19 Garmin Ltd. Traffic data quality
US8351912B2 (en) 2008-12-12 2013-01-08 Research In Motion Limited System and method for providing traffic notifications to mobile devices
EP2306424B1 (de) * 2008-12-12 2014-04-30 BlackBerry Limited System und Verfahren zur Bereitstellung von Verkehrsbenachrichtigungen auf mobile Vorrichtungen
CN102243812B (zh) * 2010-05-13 2015-04-29 阿尔派株式会社 导航装置及交通信息提示方法
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
DE102012204542A1 (de) 2012-03-21 2013-09-26 Bayerische Motoren Werke Aktiengesellschaft Verfahren und Vorrichtung zum Ermitteln eines Verkehrszustandes
CN103366551A (zh) * 2012-04-05 2013-10-23 郭海锋 一种道路交通安全评价方法
US9852637B2 (en) 2014-01-10 2017-12-26 Regents Of The University Of Minnesota Vehicle-to-vehicle congestion monitoring using ad hoc control
US10026313B2 (en) * 2014-01-10 2018-07-17 Regents Of The University Of Minnesota DSRC-equipped portable changeable sign
US9752881B2 (en) * 2014-12-23 2017-09-05 Intel Corporation Locating services
CN106781468B (zh) * 2016-12-09 2018-06-15 大连理工大学 基于建成环境和低频浮动车数据的路段行程时间估计方法
DE102017208124B4 (de) * 2017-05-15 2019-04-04 Bayerische Motoren Werke Aktiengesellschaft Verfahren, Vorrichtung und System zum Ermitteln einer Straßenbaustelle
CN109003453B (zh) * 2018-08-30 2020-05-22 中国人民解放军国防科技大学 基于支持向量机的浮动车路段平均速度短时预测方法
CN112837393B (zh) * 2019-11-22 2024-04-09 中国航天系统工程有限公司 基于车辆位置数据的特大城市矢量路网的生成方法及系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0892379A2 (de) * 1997-07-18 1999-01-20 Robert Bosch Gmbh Verfahren und Telematikgerät zum Erstellen und Aussenden von verkehrsrelevanten Daten
DE10063588A1 (de) * 1999-12-23 2001-07-12 Gedas Telematics Gmbh Verfahren zum Übermitteln von Daten zur Verkehrslagebeurteilung und ein Endgerät in einem mobilen Detektor
WO2002007125A1 (de) * 2000-07-19 2002-01-24 Volkswagen Aktiengesellschaft Verfahren zur ermittlung von verkehrslageinformationen
EP1216888A2 (de) * 2000-12-23 2002-06-26 Bayerische Motoren Werke Aktiengesellschaft Standardinterface für Fahrzeuge
EP1262934A2 (de) * 2001-06-01 2002-12-04 DDG Gesellschaft für Verkehrsdaten mbH Verfahren zur Verkehrslageerfassung
DE10219531A1 (de) * 2002-05-02 2003-11-20 Volkswagen Ag Verfahren und Datenprotokoll zum Austausch von Informationen zwischen einer Verkehrszentrale und einem Stichprobenfahrzeug

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0892379A2 (de) * 1997-07-18 1999-01-20 Robert Bosch Gmbh Verfahren und Telematikgerät zum Erstellen und Aussenden von verkehrsrelevanten Daten
DE10063588A1 (de) * 1999-12-23 2001-07-12 Gedas Telematics Gmbh Verfahren zum Übermitteln von Daten zur Verkehrslagebeurteilung und ein Endgerät in einem mobilen Detektor
WO2002007125A1 (de) * 2000-07-19 2002-01-24 Volkswagen Aktiengesellschaft Verfahren zur ermittlung von verkehrslageinformationen
EP1216888A2 (de) * 2000-12-23 2002-06-26 Bayerische Motoren Werke Aktiengesellschaft Standardinterface für Fahrzeuge
EP1262934A2 (de) * 2001-06-01 2002-12-04 DDG Gesellschaft für Verkehrsdaten mbH Verfahren zur Verkehrslageerfassung
DE10219531A1 (de) * 2002-05-02 2003-11-20 Volkswagen Ag Verfahren und Datenprotokoll zum Austausch von Informationen zwischen einer Verkehrszentrale und einem Stichprobenfahrzeug

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007062680B4 (de) * 2006-12-28 2013-05-23 Denso Corporation Verkehrsstaugradbestimmungsvorrichtung, Verkehrsstaugradmeldevorrichtung und Programm
EP1947623A1 (de) * 2007-01-17 2008-07-23 Audi Ag Verfahren und Vorrichtung zur dynamischen Klassifikation von Objekten und/oder Verkehrssituationen

Also Published As

Publication number Publication date
DE502004011688D1 (de) 2010-11-04
WO2005064564A1 (de) 2005-07-14
US20070010934A1 (en) 2007-01-11
US7869934B2 (en) 2011-01-11

Similar Documents

Publication Publication Date Title
EP1695317B1 (de) Verkehrszustandserkennung mit einem schwellenwertverfahren
DE102015100812B4 (de) Verfahren zum Verwenden von Strassenniveaubildern zum Verbessern eines Modus eines automatisierten Fahrens für ein Fahrzeug
DE102015207804B4 (de) Verfahren zum Erkennen von Parkflächen und/oder Freiflächen
EP1695295B1 (de) Überprüfung des geltungsbereichs von verkehrszustandsdaten
WO2005064566A1 (de) Ermittlung des zu erwartenden geschwindigkeitsniveaus
EP0931301B1 (de) Verfahren und vorrichtung zur übermittlung von daten zur verkehrslagebeurteilung
DE19606258C1 (de) Fahrzeugautonome Detektion von Verkehrsstau
DE102011116245B4 (de) Verfahren zur Ermittlung aktueller Streckeninformationen einer digitalen Karte
Ahmed et al. Driver performance and behavior in adverse weather conditions: an investigation using the SHRP2 naturalistic driving study data—phase 1.
DE102012219721A1 (de) Fahrassistenzverfahren und Fahrassistenzsystem zur Erhöhung des Fahrkomforts
DE112019000714T5 (de) Glasfasererfassung zur autobahninstandhaltung
WO2013091742A1 (de) Verfahren zur erzeugung und nutzung verkehrsrelevanter informationen durch fahrzeuge eines fahrzeugpools
DE10004967A1 (de) Navigationssystem und Verfahren zur Konfigurierung eines Navigationssystems
EP2856452A1 (de) Erkennung von richtungsfahrbahnen
DE102006004130B4 (de) Verfahren zur Bestimmung eines zukünftigen Straßenverlaufs durch Kommunikaiton zwischen Kraftfahrzeugen
DE102010043673A1 (de) Navigationssystem und Navigationsverfahren mit Verkehrsbeeinträchtigungs-Erkennungsfunktion
DE102013011171A1 (de) Verfahren und Vorrichtung zum automatisierten Warnblinken
EP1695314B1 (de) Erkennung von kreuzungsbereichen bei der verkehrszustandserkennung
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
EP1695320B1 (de) Verfahren zur bereitstellung von verkehrzustandsdaten
DE102009028299A1 (de) Verfahren zum Bestimmen eines am ehesten wahrscheinlichen Fahrpfads
EP1695315B1 (de) Ermittlung des zu erwartenden geschwindigkeitsniveaus
DE10327188B4 (de) Navigationsgerät für Kraftfahrzeuge und Verfahren zur Ausgabe von Verkehrslageinformationen mit einem solchen Navigationsgerät
DE102020105527A1 (de) Verfahren und system zum ermitteln von ursachen für eine verkehrsstörung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004803843

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11454784

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 2004803843

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11454784

Country of ref document: US