EP1695317B1 - Traffic status recognition with a threshold value method - Google Patents

Traffic status recognition with a threshold value method Download PDF

Info

Publication number
EP1695317B1
EP1695317B1 EP03785900A EP03785900A EP1695317B1 EP 1695317 B1 EP1695317 B1 EP 1695317B1 EP 03785900 A EP03785900 A EP 03785900A EP 03785900 A EP03785900 A EP 03785900A EP 1695317 B1 EP1695317 B1 EP 1695317B1
Authority
EP
European Patent Office
Prior art keywords
traffic
traffic status
data
step
vehicle
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.)
Active
Application number
EP03785900A
Other languages
German (de)
French (fr)
Other versions
EP1695317A1 (en
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
Priority to PCT/EP2003/014646 priority Critical patent/WO2005064567A1/en
Publication of EP1695317A1 publication Critical patent/EP1695317A1/en
Application granted granted Critical
Publication of EP1695317B1 publication Critical patent/EP1695317B1/en
Application status is Active legal-status Critical
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/01Detecting movement of traffic to be counted or controlled
    • G08G1/0104Measuring and analyzing of parameters relative to traffic conditions
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/20Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles

Abstract

The invention particularly relates to a method for provision of traffic status information, in the context of traffic status recognition (500), by means of a traffic status recognition device on a motor vehicle, in particular, traffic status information for traffic positional detection, preferably, traffic information for detection of congestion. According to the invention, qualitatively high-grade traffic information may be provided at reasonable cost, whereby, in a first step (502, 505), a multiple determination of the traffic status is carried out. In a second step, a traffic status change from the traffic status recognition device is recognised. In a third step (509, 511), a data set (510, 512, 514, 516), describing the traffic status change is generated by the traffic status recognition device, in particular, a programmed computer and the data set is transmitted in a fourth step, from the traffic status recognition device to a receiver, for receiving the data set, in particular, by short message service.

Description

  • The invention relates to a method for providing traffic status data, a system for generating and transmitting traffic status 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 the preamble of the relevant independent claim.
  • Known vehicles ship so-called floating car data (FCD). 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.
  • In order to increase the traffic situation more precisely and additionally with information about weather, road conditions and local dangers in the future, FCD will be further developed into 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 traffic conditions, obstructions, road conditions (road surface), infrastructural conditions (serpentine), local hazards, rain, slipperiness and slipping hazards.
  • From the EP-A-1 262 934 The known method comprises the following steps: detecting the vehicle position of land vehicles, detecting the speed associated with the respective land vehicle, and determining a traffic condition criterion as a function of the detected traffic Vehicle position and the detected speed. To detect traffic incidents depending on the particular road network, the following additional steps are proposed: determining a certain non-zero limit speed, comparing the detected vehicle speed of a land vehicle with the limit speed and determining a traffic condition criterion in which the limit speed is exceeded a certain value assigned.
  • The US 6,131,064 A describes a method for automatic vehicle-autonomous detection of traffic jams, wherein the speed of the vehicle in the vehicle is continuously detected. The recorded speed values are assigned to given speed classes. The associated velocity classes form the input of a temporal integration process and the result of this integration process is mapped to a limited scale to form a bubble measure. The object of the invention is in particular a method for providing high quality traffic condition data at acceptable costs.
  • This object is achieved by the independent claims each according to their genus. Advantageous embodiments are the subject of the dependent claims.
  • An essential aspect of the method according to the invention for providing traffic status data in the context of a traffic condition detection by means of a traffic condition recognition device provided in the motor vehicle is the execution of the following steps. According to the invention, the traffic condition data serve, in particular, the traffic situation detection, such as, for example, for traffic jam detection. In a first step, a traffic state is detected several times by the traffic condition recognition device, and in a second step, a traffic state change is detected or detected by the traffic state recognition device if necessary. In a third step, a traffic status change descriptive record of the traffic condition detection device, in particular a program-controlled computer generated, and finally the record is transmitted in a fourth step by the traffic condition detection device to a record receiving receiver. This should currently be done via short message service.
  • According to the traffic condition change is determined on the basis of at least two speed thresholds. Speeds below the lower speed threshold are considered congestion and speeds above the higher speed threshold are considered free. Speeds between the two speed thresholds are detected when detecting the traffic condition change by considering these speeds as undefined states in the context of detecting a change in the traffic condition, because it is not clear whether there is a congestion or no congestion or free travel.
  • By this method, in particular for the provision of traffic status data for the traffic situation detection in the entire road network, it is possible to detect a traffic event or a traffic condition change, such as a change from the traffic state "free" to the traffic condition "congestion" largely reliable and the traffic event only as given to transmit when it actually occurs, ie the inventive method allows event-driven generation of traffic condition data. Traffic condition data is transmitted only when the detected traffic condition, eg. As a traffic jam, this causes. The event-oriented data transmission to a traffic situation reconstructing and representing institution, in particular a traffic data center, currently preferably by SMS, limits the traffic situation presentation required data transfer to a minimum. This means a significant cost saving without sacrificing the quality of the traffic situation detection.
  • Rather, only the inventive method allows cost-effective, yet timely data collection for the entire road network, especially on highways, roads and on streets in city traffic.
  • In one embodiment of the invention, it is provided that the data record indicates whether a traffic state change from traffic state "traffic jam" to traffic state "free" or a traffic state change from traffic state "free" to traffic state "traffic jam" has been determined by the traffic condition recognition device provided in the motor vehicle.
  • Alternatively or additionally, it is provided in one embodiment of the invention that is repeatedly checked when determining the traffic conditions "traffic jam" or "free" whether the used speed of the vehicle is less than a lower speed threshold and greater than an upper speed threshold.
  • Alternatively or additionally, in a further embodiment of the invention, it is provided that the checking takes place periodically and that traffic condition "traffic jam" or "free" is considered to be present, which has first occurred largely continuously at a predetermined frequency.
  • Due to the continuous recording of both states and not just a single state, it is possible to reliably detect whether there is a traffic jam as well as to reliably detect whether a congestion-free onward journey is possible again. It is avoided that the determined traffic condition unreliably tilts between the two states "congestion" and "free" due to only short-term changes in the traffic condition.
  • Alternatively or additionally, in another embodiment of the invention, it is provided that the data record which describes the traffic state change additionally indicates the location and time of the traffic condition change, in particular the location and time of the traffic jam entrance or the jam exit.
  • The aforementioned measures enable precise and up-to-date traffic situation detection, in particular traffic jam detection. Unnecessary detours due to a supposedly existing congestion can be avoided in the entire road network - and not only on highways.
  • Alternatively or additionally, it is provided in one embodiment of the invention that after transmission of the data set of the traffic condition change after a predetermined time and / or path interval, the traffic data, in particular the congestion, descriptive second record is transmitted from the vehicle. This second data set indicates, in particular, the average speed in traffic jams and / or frequency of traffic in the previous interval.
  • This measure enables the automatic provision of an updated traffic situation after a first change in traffic status and before a second change in traffic status. In addition, the second record allows a closer determination of the traffic condition change in time or space.
  • Alternatively or additionally, it is provided in one embodiment of the invention that the receiver is a traffic data center, preferably a regional traffic data center, which provides a traffic situation using the data record.
  • Alternatively or additionally, it is provided in one embodiment of the invention that the traffic situation using the data set and other traffic condition data is provided, in particular data from local measuring points, such as induction loops, bridge sensors, camera systems, beacons, or moving measuring points, such as reporting vehicles, traffic jams or Police reports. This combination of traffic status data from different sources enables a largely nationwide, precise traffic situation detection. If regional transport data centers are involved, they can better take regional concerns into account than a single central authority could.
  • Alternatively or additionally, it is provided in one embodiment of the invention that the receiver is at least one other motor vehicle which evaluates the data record to assist the driver and / or forwards the data record to other vehicles and / or data collection points to the traffic data center, in particular via a wireless interface to a transmission network. This measure makes it possible for vehicles to transmit mutually relevant traffic status data, if necessary with the inclusion of a traffic data center, in particular for traffic situation detection.
  • 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.
  • The invention will be explained in more detail with reference to diagrams of a sequence control. Show it:
  • FIG. 1:
    the flow chart 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 flow diagram of a software module for determining the boundary conditions weather and road guidance,
    FIG. 4:
    the flowchart of a software module for detection of intersections, and
    FIG. 5:
    the flow diagram of a software module for detecting the traffic condition.
  • Vehicle-generated data are provided by the vehicle data buses via a known standard sensor interface, preferably every second, to a computing algorithm. In detail these are:
    • Location coordinates from: Navigation system
    • Road category from: Navigation system
    • Distance to next intersection: Navigation system
    • Distance to the end of the busy road segment from: Navigation system
    • Average normal speed off: Navigation system
    • In-town / out-of-town (road type) from: Navigation system
    • Speed off: vehicle bus
    • Steering angle from: vehicle bus
    • Gear off: vehicle bus
    • Hazard warning lights, turn signals off: vehicle bus
    • ABS from: vehicle bus
    • DSC / ASR off: vehicle bus
    • Crash sensor off: vehicle bus
    • Airbag off: vehicle bus
    • Door status off: vehicle bus
    • Next POI type from: Navigation system
    • Distance POI from: 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, gas stations, hospitals etc.
  • For checking the scope accordingly FIG. 1 will be based on the data
    • location coordinates
    • road category
    • In-town / out-of-town (road type)
    • gear selection
    • door status
    • Next POI type
    • Distance to next POI
    • steering
    • hand brake
    • air bag
    • Crash sensor
    determined whether the vehicle currently participates in the flow of traffic. The status of the vehicle doors and the current gear selection z. For example, information about whether people get in or out (door opens).
  • By evaluating the steering angle impacts in connection with the speed parking operations can be detected. 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. In 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 In a comparison, it is checked whether the parking brake is applied, in the comparison 107 it is checked whether the airbag has been triggered. If the result of one or more of these comparisons is positive or if the answer is "yes" to one of the comparisons 101 to 107, this is interpreted as indicating that the vehicle is or is moving in a situation that occurs when a congestion is detected or should not be taken into account when detecting "free travel" or "go".
  • If there is a positive comparison of one or more of the comparisons 101 to 107, preferably a comparison takes place every second, 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. If the result of the comparisons 101 to 107 has always been "no", this is considered to be a situation in which no state of emergency exists and the jam detection is carried out-as described in more detail below. This is indicated by "detection GO" 113.
  • It is advantageous to execute the comparisons 101 to 107 consecutively in sequence - instead of carrying out the comparisons (not shown) in parallel, because with at least one positive comparison, the following comparisons are no longer performed and thus computing time or hardware resources are saved. Likewise, the 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.
  • In 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, and the upper speed threshold S2 at 45 km / h is set in the table, respectively. This is an empirical value based on the assumption that at 35 km / h, a traffic disturbance is likely, a traffic disruption could exist at a speed of 35 to 45 km / h and a speed of more than 45 km / h probably no Traffic disruption or no congestion is given. The same is also entered for the other road types in the table.
  • The normal speed for the concrete road can also be specified on the digital map. Possibly. For example, 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.
  • It will be understood that these values are empirical values that can be chosen preferentially to optimize the reliability of the accumulation detection. Similarly, the speed thresholds S1 and S2 can be determined from the table even if the normal speed is recorded on the digital map.
  • In particular, a distinction is made between "road type" in the SSI: highway (freeway or highway or throughway), developed federal highway (highway or fast road), non-developed federal road (fast road or regional road), main road (main road), main road passing through a local road, connecting road, slow road, minor road, and service road. Under "Street category", a distinction is made in the SSI between "urban" and "out of town".
  • FIG. 3 shows the flowchart of the software module 300 for determining the boundary conditions weather and road guidance.
  • The SSI data:
    • wiper switch
    • wiping frequency
    • lateral acceleration
    • SECTION
    • TCS / DSC
    • steering angle
    • temperature
    • light
    • fog lamp
    allow the assessment of boundary and surrounding conditions such as snowfall, rain, slippery, or winding roads (serpentine). In case of a significant occurrence of one of these boundary conditions, the thresholds S1 and S2 for the in FIG. 5 described traffic condition detection adjusted accordingly.
  • In step 301, the value M, a value indicating the severity of the prevailing boundary conditions, is set to "0", that is, the output value for M is M0 = 0. Every second, the in FIG. 3 go through the illustrated chain. In 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. In step 304, it is compared whether the current value of Tw1 is higher than a value K1 indicating a lower time threshold. If the windscreen wiper runs longer than the lower time threshold K1, ie if the result of the comparison 304 is "yes", the value M0 is increased by the value N1 in step 305, M1 = 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". After the addition of N1 in step 305, it proceeds with the following steps further.
  • If the windshield wiper does not wipe, the comparison 302 gives a "no" and the value Tw1 is set to "0" in step 306. In this case, in the case where the comparison 304 is "No" or in the case that M1 = MO + N1 has been added, it goes to step 307. If the result is "no" in step 302 the value of Tw1 is reset to "0".
  • In step 307, the data provided by the SSI is checked to see if the ASC, the DSC or the ABS is intervening. Possibly. is the result of comparison 307 "yes". Since the in FIG. 3 2 seconds, the value Tw2 is incremented by the value "1" every second in step 308 if the intervention continues. If the value of Tw2 is greater than a lower time threshold K2, the result of the comparison 309 is "yes" and the value M1 of step 305 is added to the value N2 in step 310, ie M2 = M1 + N2. N2 is a value that expresses how great the influence on the normal speed of the vehicle without adverse marginal conditions is and thus represents a weight for the condition "ASC, DSC or ABS active". If the result of the comparison 307 is "No", Tw2 is set to "0" in step 311.
  • In the next step 312 it is checked whether the fog lamp is switched on. Possibly. If the result of the comparison 312 is "yes" and the value M2 from the step 310, the value N3 is added in step 313, ie M3 = M2 + N3. 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".
  • If the result of the comparison in step 312 has been "no" or if the value N3 has been added in step 313, step 314 is carried out. In this step, it is checked whether it is a curvy route. This can be determined on the basis of the steering angle data supplied by the SSI and its time change. If the result of the comparison 314 is "yes", the value M4 is added to the value M3 in step 315, i. M4 = M3 + N4. If the result of the comparison 314 is "No" or if step 315 has been carried out, the process continues with step 316. N4 is a value which expresses how large the influence on the normal speed of the vehicle without disadvantageous boundary conditions is and thus ceases Weight for the condition "winding route".
  • In step 316 is checked. whether the dipped beam is switched on. Alternatively, it could be checked by means of a daylight sensor, if it is dark and the low beam should be turned on. Such a sensor, which automatically turns on the low beam in the dark is known as optional "driving light control". If it is determined that the low beam is on or should be turned on because it is dark, the result of the comparison 316 is "Yes" and the value M4 is added to the value M4 in step 317, i. M5 = M4 + N5. 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".
  • If the result of the comparison is "No" or if N5 has been added in step 317, the process continues with step 318. In step 318, it is checked whether the temperature is lower than 4 degrees Celsius and, in addition, the windscreen wiper is switched on. Possibly. is the result of the comparison 318 "Yes" and in step 319 the value N5 is added to the value M5, ie M6 = M5 + N6. N6 is a value that expresses how great the influence on the normal speed of the vehicle without adverse conditions and thus represents a weight for the condition "temperature lower than 4 degrees Celsius and also wiper on" is.
  • If the result of the comparison is "No" or if N6 has been added in step 319, the process continues with step 320.
  • In 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.
  • In the next step, the in FIG. 3 the chain shown again (preferably) about every second, unless it is determined that the vehicle outside the scope of the jam detection invention (see. FIG. 1 ) is located.
  • These values for S1 and S2, which are possibly reduced by the abovementioned boundary conditions, set the values for S1 and S2 in FIG FIG. 5 showing the flowchart of the traffic detection software module. This avoids the adverse conditions that lead to a reduction in the speed traveled, without a jam, leading to the supposed detection of congestion.
  • Further, the corresponding reduced value for S1 instead of the value S1 in FIG. 4 showing the flow diagram of a software module for detecting intersection areas.
  • 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.
  • In a step 401, it is checked whether the distance s of the vehicle to the next intersection is smaller than a predetermined distance S3. Based on test drives, a value of approx. 160 m is currently preferred for S3. If the result of the comparison is "yes", it is checked in step 402 whether the speed v of the vehicle is less than the currently valid lower speed threshold S1. As already stated, this may be the reduced value for S1 (cf. Fig. 3 ). If the result of the comparison is "yes", the actual speed v of the vehicle will not be referred to the traffic condition detection of the vehicle as speed v2 FIG. 5 but in step 403, the average speed of the vehicle during the last 60 seconds before the comparison in step 402, ie v2 = v (t-60). This average speed v2 is therefore an intersection-adjusted (modified) speed.
  • 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.
  • In the next step, the in FIG. 4 the chain shown again (preferably) about every second, unless it is determined that the vehicle outside the scope of the jam detection invention (see. FIG. 1 ) is located.
  • FIG. 5 Finally, 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. In addition, 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.
  • After the steps 111 (detection PAUSE), 112 (detection RESET) or 113 (detection GO), it is checked whether "detection PAUSE" is present. If the result is "no" then the in FIG. 5 illustrated process steps without a change in the counter readings of the counter described below. If the result is "yes", it is checked whether "RESET detection" is also present. If "RESET RESPONSE" is present, ie if the result of this comparison is "yes", the counter readings of the two counters described below are respectively reset to the count "0" and the method steps of FIG. 5 are then continued with the counter readings "0". If there is no "RESET detection", the method steps of FIG. 5 after the pause (detection PAUSE) continues with the counter readings given at this time.
  • In summary, 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.
  • In 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. If appropriate, the counter reading in step 502 preferably increases by the value "1" every second, ie, preferably W1 = 1. Of course, another value, such as "0.5", could also be added. The state of the counter in step 502 is compared in step 503 with a value S5 (count 1> S5).
  • 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. If appropriate, 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.
  • Based on the comparison 501, 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". Then, in step 507, the second counter that counts how many seconds of free travel is given is reset to "0" (count 2 = 0). Starting from the comparison 504, 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". Then, in step 508, the first counter that counts how many seconds there is a jam is reset to "0" (count 1 = 0).
  • In 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.
  • After steps 513, 514, 515 and 516, in 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 (| counter reading 1 - counter reading 2 |> S9). If the result of the comparison is "yes", step 509 is executed. If the result of the comparison is "no", step 509 is not executed and the in FIG. 5 The process chain shown starts again with step 501, as in the preferably one-second run.
  • 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.
  • If the count of the first counter is less than S5 or equal to S5, the result of the comparison 503 is "No". In 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. Preferably W1 and W2 have the same value, W3 preferably having half the value of W1 or W2. Preferably, 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. If the result of the comparison is "yes", 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.
  • If the count of the first counter is less than or equal to a value S6, the result of the comparison is "no". Possibly. In 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". If the result of the comparison is "yes", the second data set and the location and time of the (previously only potential) congestion exit in step 521 for the purpose of data collection to an organization reconstructing and representing the traffic situation, in particular a traffic data center, preferably a regional traffic data center , preferably by SMS, transmitted.
  • If the result of the comparisons in steps 518 or 520 is "no", no data transmission takes place. Rather, that starts in FIG. 5 described method again with step 501.
  • 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.
  • After the issue of the status "congestion" or "free" or if the comparison 511 is "no", the in FIG. 5 go through the chain shown again.
  • 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.
  • 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. When transmitting the state "free" in step 512, preferably 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.
  • 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.
  • Preferably, 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.

Claims (12)

  1. A method for providing traffic status data in the framework of recognising a change in the traffic status with the traffic statuses "jam" and "clear", by means of a traffic status recognition device provided in the motor vehicle, characterised in that, in a first step, a traffic status is repeatedly detected by the traffic status recognition device, in a second step, a check is made by the traffic status recognition device whether a traffic status change has occurred (518, 520), in a third step (519, 521), if a traffic status change has occurred, a data record (510, 512, 514, 516) describing the traffic status change is produced by the traffic status recognition device, and the data record is transmitted, in a fourth step, from the traffic status recognition device to a receiver receiving the data record, wherein the data status change is determined on the basis of at least two speed thresholds, speeds below the lower speed threshold value being considered a jam and speeds above the upper speed limit being considered as clear and speeds between the two speed thresholds being taken into account in the detection of the traffic status change, in which these speeds are observed in the framework of the recognition of a change of the traffic status as non-defined statuses, because it is not clear whether a jam or no jam or clear journey as occurred.
  2. A method according to claim 1, characterised in that the data record states whether a traffic status change from the traffic status "jam" to the traffic status "clear" (510) or a traffic status change from the traffic status "clear" to the traffic status "jam" (512) has been established by the traffic status recognition device provided in the motor vehicle.
  3. A method according to claim 1 or 2, characterised in that when the traffic statuses "jam" or "clear" are determined, a check is made several times as to whether the speed of the vehicle used is less than a lower speed threshold (501) and greater than an upper speed threshold (502).
  4. A method according to claim 3, characterised in that the checking takes place periodically and the traffic status "jam" or "clear" which has first occurred with a predetermined frequency (509, 511), substantially uninterrupted, is considered to be present.
  5. A method according to any one of claims 1 to 4, characterised in that the data record, which describes the traffic status change, additionally gives the location (514) and the time of the traffic status change.
  6. A method according to any one of claims 1 to 5, characterised in that after transmission of the data record of the traffic status change, after a predetermined time or route interval, a data record describing the traffic status is transmitted by the vehicle.
  7. A method according to any one of the preceding claims, characterised in that the receiver is a traffic data centre, which provides a traffic situation using the data record.
  8. A method according to any one of the preceding claims, characterised in that the traffic situation is provided using the data record and further traffic status data.
  9. A method according to any one of claims 1 to 6, 8, characterised in that the receiver is at least one other motor vehicle, which evaluates the data record to assist the driver and/or passes the data record to other vehicles and/or via data collection points to the traffic data centre.
  10. A system for transmitting traffic status data from a first vehicle to a second vehicle, more especially via an ad-hoc network, or from a traffic data centre to one or more motor vehicles, characterised in that the data acquisition takes place by means of the traffic statuses by a method according to any one of the preceding method claims.
  11. A device in a motor vehicle for generating and sending traffic status data, characterised in that the device generates and sends traffic status data corresponding to one of the preceding method claims.
  12. A computer programme product for use in a motor vehicle and for generating and sending traffic status data, characterised in that the computer programme product allows a method according to any one of the preceding method claims to run.
EP03785900A 2003-12-19 2003-12-19 Traffic status recognition with a threshold value method Active EP1695317B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2003/014646 WO2005064567A1 (en) 2003-12-19 2003-12-19 Traffic status recognition with a threshold value method

Publications (2)

Publication Number Publication Date
EP1695317A1 EP1695317A1 (en) 2006-08-30
EP1695317B1 true EP1695317B1 (en) 2008-10-08

Family

ID=34717113

Family Applications (1)

Application Number Title Priority Date Filing Date
EP03785900A Active EP1695317B1 (en) 2003-12-19 2003-12-19 Traffic status recognition with a threshold value method

Country Status (4)

Country Link
US (1) US7343242B2 (en)
EP (1) EP1695317B1 (en)
DE (1) DE50310628D1 (en)
WO (1) WO2005064567A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106297321A (en) * 2016-08-29 2017-01-04 成都汉康信息产业有限公司 A kind of urban congestion section wagon flow instruction monitoring system

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6587781B2 (en) 2000-08-28 2003-07-01 Estimotion, Inc. Method and system for modeling and processing vehicular traffic data and information and applying thereof
US7221287B2 (en) 2002-03-05 2007-05-22 Triangle Software Llc Three-dimensional traffic report
WO2005013063A2 (en) 2003-07-25 2005-02-10 Landsonar, Inc. System and method for determining recommended departure time
US7620402B2 (en) 2004-07-09 2009-11-17 Itis Uk Limited System and method for geographically locating a mobile device
US7590490B2 (en) * 2006-01-09 2009-09-15 Mitac International Corporation Smart detour
AT391980T (en) * 2006-02-02 2008-04-15 Fiat Ricerche System for detecting vehicle traffic by means of extended template cooperation platform based on advanced sample vehicle data
JP4729440B2 (en) * 2006-06-07 2011-07-20 日立オートモティブシステムズ株式会社 Communication system, communication terminal, and information processing apparatus
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
JP4984974B2 (en) * 2007-03-02 2012-07-25 富士通株式会社 Driving support system and in-vehicle device
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
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
US8700314B2 (en) 2008-01-18 2014-04-15 Mitac International Corporation Method and apparatus to search for local parking
US8290703B2 (en) 2008-01-18 2012-10-16 Mitac International Corporation Method and apparatus for access point recording using a position device
KR20110026433A (en) * 2008-06-25 2011-03-15 톰톰 인터내셔날 비.브이. Navigation apparatus and method of detection that a parking facility is sought
US8626208B2 (en) * 2008-06-30 2014-01-07 General Motors Llc Traffic data transmission from a vehicle telematics unit
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
GR1006698B (en) * 2008-12-22 2010-02-05 Φωτησ Λιοτοπουλοσ Method and system for the collection, processing and distribution of traffic data for optimizing routing in satellite navigation systems of vehicles.
GB0901588D0 (en) 2009-02-02 2009-03-11 Itis Holdings Plc Apparatus and methods for providing journey information
US8619072B2 (en) * 2009-03-04 2013-12-31 Triangle Software Llc Controlling a three-dimensional virtual broadcast presentation
US9046924B2 (en) * 2009-03-04 2015-06-02 Pelmorex Canada Inc. Gesture based interaction with traffic data
US8982116B2 (en) * 2009-03-04 2015-03-17 Pelmorex Canada Inc. Touch screen based interaction with traffic data
US8386168B2 (en) * 2009-11-24 2013-02-26 Verizon Patent And Licensing Inc. Traffic data collection in a navigational system
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
US8897948B2 (en) * 2010-09-27 2014-11-25 Toyota Systems and methods for estimating local traffic flow
US8718910B2 (en) 2010-11-14 2014-05-06 Pelmorex Canada Inc. Crowd sourced traffic reporting
US20120146809A1 (en) * 2010-12-13 2012-06-14 Samsung Electronics Co. Ltd. Information providing apparatus and method for vehicles
CA2839866A1 (en) 2011-05-18 2012-11-22 Triangle Software Llc System for providing traffic data and driving efficiency data
GB2492369B (en) 2011-06-29 2014-04-02 Itis Holdings Plc Method and system for collecting traffic data
US8706397B2 (en) * 2011-07-11 2014-04-22 Harman International Industries, Incorporated System and method for determining an optimal route using aggregated route information
US8554468B1 (en) * 2011-08-12 2013-10-08 Brian Lee Bullock Systems and methods for driver performance assessment and improvement
WO2013113029A1 (en) * 2012-01-27 2013-08-01 Triangle Software, Llc Estimating time travel distributions on signalized arterials
US10223909B2 (en) * 2012-10-18 2019-03-05 Uber Technologies, Inc. Estimating time travel distributions on signalized arterials
DE102012204542A1 (en) 2012-03-21 2013-09-26 Bayerische Motoren Werke Aktiengesellschaft Method and device for determining a traffic condition
US8972175B2 (en) * 2013-03-14 2015-03-03 Qualcomm Incorporated Navigation using crowdsourcing data
CN106683399A (en) * 2015-11-10 2017-05-17 湖南南车时代电动汽车股份有限公司 Method of acquiring road condition state of bus

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2999339B2 (en) * 1993-01-11 2000-01-17 三菱電機株式会社 Vehicle path guide apparatus
EP0715286B1 (en) * 1994-11-28 1999-01-07 MANNESMANN Aktiengesellschaft Method for reducing the amount of data to be transmitted from vehicles of a fleet of sample vehicles
DE19606258C1 (en) * 1996-02-06 1997-04-30 Mannesmann Ag Vehicle autonomous traffic jam detection method
WO1997029470A1 (en) * 1996-02-08 1997-08-14 Mannesmann Ag Process for obtaining traffic data
WO1997029471A1 (en) * 1996-02-08 1997-08-14 Mannesmann Ag Process and device for obtaining traffic situation data
DE19643454C2 (en) * 1996-10-10 2003-08-21 Mannesmann Ag Method and apparatus for transmitting data on the traffic situation assessment
DE19917154B4 (en) * 1999-04-16 2013-09-05 Deutsche Telekom Ag Method for detecting congestion situations on roads and vehicle equipment with a unit for carrying out the method
DE10036789A1 (en) * 2000-07-28 2002-02-07 Daimler Chrysler Ag Method for determining the traffic state in a traffic network with effective bottlenecks
DE10126872A1 (en) * 2001-06-01 2003-01-02 Ddg Ges Fuer Verkehrsdaten Mbh A method for detecting a traffic situation
US6650252B2 (en) * 2001-08-28 2003-11-18 Delphi Technologies, Inc. Vehicle warning system and method
US6708107B2 (en) * 2002-04-02 2004-03-16 Lockheed Martin Corporation Real-time ad hoc traffic alert distribution
DE10215887B4 (en) * 2002-04-11 2013-11-07 Deutsche Telekom Ag Asynchronous traffic data collection
GB0220062D0 (en) * 2002-08-29 2002-10-09 Itis Holdings Plc Traffic scheduling system

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106297321A (en) * 2016-08-29 2017-01-04 成都汉康信息产业有限公司 A kind of urban congestion section wagon flow instruction monitoring system

Also Published As

Publication number Publication date
US7343242B2 (en) 2008-03-11
EP1695317A1 (en) 2006-08-30
DE50310628D1 (en) 2008-11-20
WO2005064567A1 (en) 2005-07-14
US20060287808A1 (en) 2006-12-21

Similar Documents

Publication Publication Date Title
CA2531662C (en) Traffic information system
US7990286B2 (en) Vehicle positioning system using location codes in passive tags
US7680588B2 (en) Traffic information management system
US9430944B2 (en) Method and apparatus for determining traffic safety events using vehicular participative sensing systems
EP1960982B1 (en) Vehicular drive assist system and vehicular drive assist method
JP5707510B2 (en) Method for distinguishing traffic data obtained from probe vehicles
US10083607B2 (en) Driver safety enhancement using intelligent traffic signals and GPS
DE102015202367A1 (en) Autonomic control in a sealed vehicle environment
US6995663B2 (en) Driving workload estimation
US20100007523A1 (en) Driver alert system
US8433504B2 (en) Traffic information generation method, traffic information generation device, and navigation system
US20170076600A1 (en) Condition-based lane suggestions for travel advising
US7406382B2 (en) System for determining weather information and providing ambient parameter data
US7804423B2 (en) Real time traffic aide
JP3526460B2 (en) Quantitative data estimation methods and exploration vehicle to be applied thereto Hyosuru traffic flow
EP1176569B1 (en) Method for monitoring the condition of traffic for a traffic network comprising effective narrow points
US20130162449A1 (en) Traffic Routing Using Intelligent Traffic Signals, GPS and Mobile Data Devices
US8239123B2 (en) System and method for exchanging positioning information between vehicles in order to estimate road traffic
EP2638711B1 (en) A vehicle data system and method
US20050143889A1 (en) Vehicle driving assistance apparatus and method
US9330564B2 (en) Method and system for using intersecting electronic horizons
US8209114B2 (en) Traffic information generating apparatus and traffic information generating method
CN103164986B (en) Exceptional road-condition warning system and method for a vehicle
CN101652802B (en) Safe driving assisting device
US7783420B2 (en) Route guidance systems, methods, and programs

Legal Events

Date Code Title Description
AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

17P Request for examination filed

Effective date: 20060512

17Q First examination report despatched

Effective date: 20061009

RBV Designated contracting states (corrected)

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

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR GB

REF Corresponds to:

Ref document number: 50310628

Country of ref document: DE

Date of ref document: 20081120

Kind code of ref document: P

26N No opposition filed

Effective date: 20090709

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 from national office to epo]

Ref country code: DE

Payment date: 20181211

Year of fee payment: 16

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

Ref country code: GB

Payment date: 20181219

Year of fee payment: 16

Ref country code: FR

Payment date: 20181218

Year of fee payment: 16