Not Applicable
Not Applicable
1. Field of Invention
This invention pertains to a system for reporting and monitoring vehicular traffic status. More particularly, this invention pertains to transceivers in vehicles that receive, transmit, and repeat local traffic and vehicle information. Traffic status is determined by decentralized processing.
2. Description of the Related Art
Portable communications devices offer many services, including access to the global positioning system (GPS), access to the internet, and cameras, both still and video. Many of these portable communications devices are built into vehicles.
U.S. Pat. No. 6,480,121, titled “Comprehensive information and service providing system,” issued to Reimann on Nov. 12, 2002, discloses a system that provides services to mobile units, including weather information, Internet access, and police and emergency services. Reimann further discloses displaying traffic status maps provided by a central service provider 46, who collects and compiles the traffic data.
U.S. Pat. No. 6,580,909, titled “Communications System and Method Based on the Relative Positions of Mobile Units,” and issued to Carro on Jun. 17, 2003 discloses a network of mobile communications units. Carro discloses peer-to-peer wireless communications enabled between mobile communications units so that a fleet of mobile units form a meshed network that does not require a base station to operate.
According to one embodiment of the present invention, a decentralized, mobile system for reporting and monitoring vehicular traffic status is provided. A vehicle has a position determining device, a transceiver, and a local display and controller connected to a processor. The transceiver receives, transmits, and repeats local traffic and vehicle information, such as location, direction, and speed, with other vehicles having a transceiver. The processor determines local traffic conditions based on the received data.
The above-mentioned features of the invention will become more clearly understood from the following detailed description of the invention read together with the drawings in which:
A decentralized, mobile system for reporting and monitoring vehicular traffic status is disclosed.
The system relies on messages sent by each participating vehicle 102. A participating vehicle is one that contains a mobile traffic unit 10 that is operational. The mobile traffic unit 10 in each vehicle 102 broadcasts that vehicle's location and speed information. By processing the data that is received from vehicles 102 that are on the same roads and going the same direction, the unit can display traffic information, including indications that the traffic has slowed far below the normal speed limit for that particular route.
The vehicle information, in the illustrated embodiment, is gathered from the position determining device, or global positioning system receiver, 204 and the vehicle sensors 214. The GPS provides the location of the vehicle and the time and date, and the vehicle sensors 214 provide information regarding the vehicle speed and direction of travel. In another embodiment, the GPS 204, in combination with the processor 206, provides the location of the vehicle, the vehicle speed, the direction of travel, and the time and date, without resort to the vehicle sensors 214. The speed and direction of travel is determined by comparing multiple readings from the GPS 204 to determine the distance traveled for a period of time and the direction of travel over that time.
The processor 206 should be broadly construed to mean any computer or component thereof that executes software. In one embodiment the processor 206 is a general purpose computer, in another embodiment, it is a specialized device for implementing the functions of the invention. Those skilled in the art will recognize that the processor 206 includes an input component, an output component, a storage component, and a processing component. The input component receives input from external devices, such as the position determining device 204 and the transceiver 208. The output component sends output to external devices, such as the transceiver 208 and the display and control unit 212. The storage component stores data and program code. In one embodiment, the storage component includes random access memory. In another embodiment, the storage component includes non-volatile memory, such as floppy disks, hard disks, and writeable optical disks. Those skilled in the art will recognize that the components associated with the processor 206 can be either internal or external to the processing unit of the processor 206 without departing from the scope and spirit of the present invention. The processing component executes the instructions included in the software and routines. Those skilled in the art will recognize that it is possible to program a general-purpose computer or a specialized device to implement the invention.
The transceiver 208 receives, transmits, and repeats local traffic and vehicle information, including location, direction, and speed, with other vehicles 102 having a mobile traffic unit 10. In the illustrated embodiment, each mobile traffic unit 10 is equipped with a digital data radio frequency (RF) transceiver 208 that transmits and receives packets. Those skilled in the art will recognize that individual transmitters and receivers can be used without departing from the spirit and scope of the present invention. The transceiver 208, in one embodiment, has a low transmit power of approx 0.25 Watts. Such a low power transceiver 208 is insufficient for communicating over more than one mile. In order for the system to send a particular packet farther than this, each vehicle acts as a repeater of the packets that it receives. The communication protocol for one embodiment of the mobile traffic unit 10 consists of frequency shift keying (FSK) digital modulation using a single RF carrier center frequency. At a data rate of 1 megabit per second, each packet will take 180 microseconds to transmit.
Transmission and reception of packets may occur on one or more frequencies or codes in cases where code-division multiple access (CDMA) is used as the RF communication protocol. The packets are sent at a preselected interval by each vehicle. The transmission of each vehicle's information is on a single frequency and/or code. In one embodiment, the packet includes a 32 bit preamble, 5 bits indicating the packet type, 3 bits indicating vehicle type, 16 bits for the repeat count, a 32 bit unique originator ID, a 16 bit packet sequential ID, 32 bits for the time and date of packet origination (to the nearest second), 16 bits for the road in use, 4 bits for the direction of travel, 8 bits for the speed of the vehicle 102, and 16 bits for the CRC, for a total packet size of 180 bits, not including the preamble.
The preamble is a repetitive pattern that is easily distinguished by a receiver. Typically, this is an alternating 0, 1 pattern for 28 bits while the last 4 bits are 0, 0, 1, 1. The packet type field indicates whether the packet is from a moving vehicle 102, an emergency vehicle, or a fixed traffic warning. The field has additional bits to allow for future expansion of capabilities. The vehicle type field indicates the class of the vehicle 102 reporting its speed. This is provided because a traffic problem for one class of vehicle 102 such as large trucks may not cause a problem for other classes of vehicles 102. A motorcycle may maneuver around backed-up traffic and report an abnormally high speed. In one embodiment, this report is ignored by other classes of vehicles 102. The repeat count indicates how many times a packet has been forwarded by a mobile traffic unit 10. The generating mobile traffic unit 10 sends its own packets out with this field set to zero. When a packet is repeated by a mobile traffic unit 10, this field is incremented by 1. This field (and the CRC field) is the only field that is modified by a mobile traffic unit 10 when it repeats a packet.
The unique originator ID is a distinguishing number that allows packets from a particular vehicle 102 to be identified. For privacy protection this number changes every time the mobile traffic unit 10 is enabled. A system that continuously broadcasts a motorist's position and speed will be resisted by the market place unless methods of making the data anonymous are employed. In one embodiment, anonymous data is provided by the mobile traffic unit 10 selecting a fresh unique originator ID for the packets every time the vehicle is started. In one embodiment, this unique originator ID number is selected by a random number generator using a combination of the vehicle's VIN number and the time of day of power up as the seed for a random number generator. In another embodiment, privacy protection is accomplished by a power switch on the display and control unit 212 that allows the user to completely disable the operation of the system.
The packet sequential ID field indicates a sequential serial number of the packet that the mobile traffic unit 10 generates. Each time a vehicle 102 is started, this field is reset to zero. Each subsequent packet that the mobile traffic unit 10 generates has the value of this field incremented. The time and date of packet origination field is used to time stamp a packet. In one embodiment, the time and date are derived from the GPS data and are sent as UTC (GMT). The road in use field indicates the specific highway or road on which the vehicle is traveling 102. A special code is reserved for cases where the mobile traffic unit 10 cannot identify the road in use. The direction of travel field indicates in which lane the vehicle 102 is traveling.
The speed field indicates the speed of the vehicle 102. In one embodiment, the reported speed is capped at the speed limit for the road in use at the vehicle's location. This prevents the “self incrimination” that would occur if the mobile traffic unit 10 reported a speed over the speed limit. Such a cap has no adverse impact on the system since it is intended to warn of congested, low-speed situations.
The CRC field is the “Cyclic Redundancy Check” and allows a receiver to determine if the packet was received with no errors. If errors were received, the packet is discarded.
As the local mobile traffic unit 10 receives packets from other vehicles 102 it maintains a database that builds a picture of the condition of traffic flow within various segments of each road for which it receives data. The database contains the location and average speed of each vehicle 102 that is traversing these road segments. In one embodiment, as part of storing the message 308, the database is resorted after the message is placed in the database. The step of storing the message 308, in another embodiment, includes the step of scanning the messages contained in the database to identify and delete messages that have expired, or are obsolete. Expired messages are those that are older than a specified age. In another embodiment, the removal of expired, or obsolete, messages is performed as an independent process outside the process illustrated in
If the message is not to be repeated, the process stops. If the message is to be repeated, the message is examined to determine if it is stale 404. In one embodiment, a packet is defined as stale if its age, based on the time of its origination, divided by the distance from its origination is greater than 0.1 minutes per mile. If the message is stale, the process waits for the next message 306. If the message is not stale, the repetition count is examined to determine if it equals or exceeds the maximum packet repetition count 406. If the maximum packet repetition count has been reached, the process waits for the next message 306. If not, a random number is generated 408 and the local traffic RF density is generated 410. The random number is compared to the local traffic RF density 412. If the random number is larger, the process stops. If the local traffic RF density is larger, then the message is transmitted 414.
After receiving a packet, the process applies a set of rules to the packet to decide whether to repeat it 310. In various embodiments, the following rules are applied:
1. If the packet originated from the receiving mobile traffic unit 10, never repeat it.
2. If the packet has a flag indicating that it should not be repeated, never repeat it.
3. If the packet is “stale,” never repeat it.
4. If the packet has already been repeated, do not repeat it again.
5. If the maximum packet repetition count is exceeded for a packet, do not repeat it.
6. If the packet originated from a great distance (>500 ml), decrease the probability that it be repeated.
7. If the local traffic RF density is very heavy, only allow packets that originated from the direction in which the mobile traffic unit 10 is traveling to be repeated.
8. If a packet is received with a repeat count that is higher than the count of the packet that was received previously (indicating that another mobile traffic unit 10 within range has already repeated it), do not repeat it
9. If none of the above conditions are met, repeat the packet using a probability that is based on the local traffic RF density.
The local mobile traffic unit 10 can determine the local traffic RF density by measuring the number of packets that it receives within a given interval that have a repeat count of zero, indicating that the packet originated from a mobile traffic unit 10 within the range of direct RF communication.
The interval that a vehicle sends its packet is based on the local traffic RF density and the driving conditions of that vehicle. In light traffic when the vehicle is traveling at the speed limit for the road that it is using, in one embodiment, the packets will be broadcast at a rate of approximately three per minute. If the vehicle is in heavy traffic the reporting will be slowed to as low as one packet per minute. In another embodiment, the packet origination frequency is based on distance traveled. In this embodiment, the packets are generated no less frequently than four per mile. In slow driving conditions the packets are originated no less frequently than one per minute.
The location is compared to the last location reported 606, and if the location is on the same road, the current time is compared to the time of the last reported location to determine if it is time to report 608. If it is not time to report 608, the process returns to the collect data step 602. If the vehicle 102 is located on a different road, the time to report 608 test is skipped. If the location information is to be reported, the message is generated 610 and then transmitted 414.
The display and control unit 212, in one embodiment, includes a user interface allowing the user to control the image scale, that is, the user can zoom the map image to a larger or smaller scale, thereby increasing the area displayed or increasing the visible detail by showing an image with less area. If the scale is increased, the process illustrated in
The map image, in one embodiment, includes a graphical depiction of the roads and landmarks for a specified area surrounding the vehicle 102. The status information showing the traffic conditions is to overlay the generated status 710 data over the map image to form a composite map image. Traffic is determined by the vehicles 102 reporting vehicle information through a mobile traffic unit 10. The traffic status, in one embodiment, is presented by showing road segments in a specified color. Traffic that is flowing normally is indicated by road segments shown in green. Traffic that is slowed to a fraction of the speed limit are shown as yellow. When traffic is slowed to a stand-still the location of the slow traffic is shown in red or another suitable color. For example, road segments over which at least 90% of the traffic is moving at the speed limit are shown in green. Road segments over which more than 50% of the traffic is moving at 10 to 25 miles per hour less than the speed limit are shown in yellow. Road segments over which more than 50% of the traffic is moving at 0 to 20 miles per hour are shown in red, and road segments over which more than 90% of the traffic is moving at 0 to 5 miles per hour are shown in magenta. In various embodiments, the specific colors, speeds, and percentages for displaying status information are controlled by the user through the display and control unit 212 and the processor 206, which includes software allowing the user to specify custom colors and features.
The traffic status includes unsafe or unusual traffic conditions sent by a base station 104. This information is reported via the display and control unit 212 in such a manner that the location and urgency of the message is indicated.
In another embodiment, instead of a composite map image, the display and control unit 212 indicates the traffic status of the vehicles' current location by a colored indicator, using such colors as indicated above for traffic conditions. In still another embodiment, the display and control unit 212 indicates the traffic status of the vehicles' current location by displaying a textual message. In one embodiment, exemplary messages include “Traffic OK,” “Slow Traffic ahead,” “Traffic Slows in 2.2 miles,” and “Traffic Stopped.” In various embodiments, the display and control unit 212 indicates the traffic status of the vehicles' current location through a combination of a display of a composite map image, colored indicators, textual messages and/or verbal messages.
In one embodiment, each of the functions identified in above are performed by one or more software routines run by the processor 206. In another embodiment, one or more of the identified functions are performed by hardware and the remainder of the functions are performed by one or more software routines run by the processor 206. In still another embodiment, the functions are implemented with hardware, with the processor 206 providing routing and control of the entire integrated system 10.
The processor 206 executes software, or routines, for performing various functions. These routines can be discrete units of code or interrelated among themselves. Those skilled in the art will recognize that the various functions can be implemented as individual routines, or code snippets, or in various groupings without departing from the spirit and scope of the present invention. As used herein, software and routines are synonymous. However, in general, a routine refers to code that performs a specified function, whereas software is a more general term that may include more than one routines or perform more than one function.
The processor 206 is programmed to execute various processes. These processes require communication with other components. Those skilled in the art will recognize that additional sub-processes can be utilized without departing from the spirit and scope of the present invention. The performance of these processes, in combination with the other components of the mobile traffic unit 10, forms a method of operation.
One such process is illustrated in
Another such process is illustrated in
Another such process is illustrated in
Another such process is illustrated in
Another such process is illustrated in
The decentralized, mobile system for reporting and monitoring vehicular traffic status includes various functions. The function of acquiring vehicle data is implemented, in one embodiment, by the position determining device, or global positioning system receiver, 204 and the vehicle sensors 214. In another embodiment, the function of determining vehicle data is implemented by the GPS 204 in combination with the processor 206. In this embodiment, the processor 206 determines the speed and direction of travel by comparing multiple readings from the GPS 204 to determine the distance traveled for a period of time and the direction of travel over that time.
The function of transmitting vehicle data is implemented, in one embodiment, by the transceiver 208 and the processor 206. In another embodiment, the function of transmitting vehicle data is implemented by a separate transmitter. In both embodiments, the processor 206 executes software for reporting vehicle data through a vehicle message, repeating received messages, and transmitting the transmitted message. The function of receiving a received message from a plurality of other vehicles is implemented, in one embodiment, by the transceiver 208 and the processor 206. In another embodiment, the function of receiving a message from a plurality of other vehicles is implemented by a separate receiver. In both embodiments, the processor 206 executes software for receiving said received message.
The function of repeating a received message from other vehicles is implemented, in one embodiment, by the transceiver 208 and the processor 206. In another embodiment, the function of repeating a received message from other vehicles is implemented by a separate receiver. In both embodiments, the processor 206 executes software for repeating a received message.
The function of displaying traffic status information is performed by the processor 206 and the display unit 212. The processor 206 executes software for displaying traffic status information. The function of disabling the mobile traffic unit 10 is performed by a power switch on the display and control unit 212 that allows the user to completely disable the operation of the system. The function of preventing self-incrimination is performed by capping the reported speed in the vehicle message to the speed limit for the road in use at the vehicle's location.
From the foregoing description, it will be recognized by those skilled in the art that a decentralized, mobile system for reporting and monitoring vehicular traffic status has been provided. The system includes several mobile traffic units located within a specific area. Each mobile traffic unit includes a position determining device, such as a global positioning system receiver, connected to a processor, which is connected to a transceiver for communicating with other mobile traffic units. The mobile traffic unit also includes a display and control unit connected to the processor for interacting with the user in the vehicle.
While the present invention has been illustrated by description of several embodiments and while the illustrative embodiments have been described in considerable detail, it is not the intention of the applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus and methods, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of applicant's general inventive concept.
Number | Name | Date | Kind |
---|---|---|---|
4063073 | Strayer | Dec 1977 | A |
5389934 | Kass | Feb 1995 | A |
5543789 | Behr et al. | Aug 1996 | A |
6204808 | Bloebaum et al. | Mar 2001 | B1 |
6314366 | Farmakis et al. | Nov 2001 | B1 |
6480121 | Reimann | Nov 2002 | B1 |
6487500 | Lemelson et al. | Nov 2002 | B1 |
6564149 | Lai | May 2003 | B1 |
6580909 | Carro | Jun 2003 | B1 |
6611755 | Coffee et al. | Aug 2003 | B1 |
6848657 | Young et al. | Feb 2005 | B1 |
20010037174 | Dickerson | Nov 2001 | A1 |
20050083211 | Shafir et al. | Apr 2005 | A1 |
20050088318 | Liu et al. | Apr 2005 | A1 |
Number | Date | Country | |
---|---|---|---|
20050099321 A1 | May 2005 | US |