Patent Grant
8610596
The present invention is generally directed to traffic control preemption systems.
Traffic signals have long been used to regulate the flow of traffic at intersections. Generally, traffic signals have relied on timers or vehicle sensors to determine when to change traffic signal lights, thereby signaling alternating directions of traffic to stop, and others to proceed.
Emergency vehicles, such as police cars, fire trucks and ambulances, generally have the right to cross an intersection against a traffic signal. Emergency vehicles have in the past typically depended on horns, sirens and flashing lights to alert other drivers approaching the intersection that an emergency vehicle intends to cross the intersection. However, due to hearing impairment, air conditioning, audio systems and other distractions, often the driver of a vehicle approaching an intersection will not be aware of a warning being emitted by an approaching emergency vehicle.
Traffic control preemption systems assist authorized vehicles (police, fire and other public safety or transit vehicles) through signalized intersections by making a preemption request to the intersection controller. The controller will respond to the request from the vehicle by changing the intersection lights to green in the direction of the approaching vehicle. This system improves the response time of public safety personnel, while reducing dangerous situations at intersections when an emergency vehicle is trying to cross on a red light. In addition, speed and schedule efficiency can be improved for transit vehicles.
There are presently a number of known traffic control preemption systems that have equipment installed at certain traffic signals and on authorized vehicles. One such system in use today is the Opticom® system. This system utilizes a high power strobe tube (emitter), located in or on the vehicle, that generates light pulses at a predetermined rate, typically 10 Hz or 14 Hz. A receiver, which includes a photo detector and associated electronics, is typically mounted on the mast arm located at the intersection and produces a series of voltage pulses, the number of which are proportional to the intensity of light pulses received from the emitter. The emitter generates sufficient radiant power to be detected from over 2500 feet away. The conventional strobe tube emitter generates broad spectrum light. However, an optical filter is used on the detector to restrict its sensitivity to light only in the near infrared (IR) spectrum. This minimizes interference from other sources of light.
Intensity levels are associated with each intersection approach to determine when a detected vehicle is within range of the intersection. Vehicles with valid security codes and a sufficient intensity level are reviewed with other detected vehicles to determine the highest priority vehicle. Vehicles of equivalent priority are selected in a first come, first served manner. A preemption request is issued to the controller for the approach direction with the highest priority vehicle travelling on it.
Another common system in use today is the Opticom® GPS priority control system. This system utilizes a GPS receiver in the vehicle to determine location, speed, and heading of the vehicle. The information is combined with security coding information that consists of an agency identifier, vehicle class, and vehicle ID and is broadcast via a proprietary 2.4 GHz radio.
An equivalent 2.4 GHz radio located at the intersection along with associated electronics receives the broadcasted vehicle information. Approaches to the intersection are mapped using either collected GPS readings from a vehicle traversing the approaches or using location information taken from a map database. The vehicle location and direction are used to determine on which of the mapped approaches the vehicle is approaching toward the intersection and the relative proximity to it. The speed and location of the vehicle are used to determine the estimated time of arrival (ETA) at the intersection and the travel distance from the intersection. ETA and travel distances are associated with each intersection approach to determine when a detected vehicle is within range of the intersection and, therefore, a preemption candidate. Preemption candidates with valid security codes are reviewed with other detected vehicles to determine the highest priority vehicle. Vehicles of equivalent priority are generally selected in a first come, first served manner. A preemption request is issued to the controller for the approach direction with the highest priority vehicle travelling on it.
With metropolitan-wide networks becoming more prevalent, additional means for detecting vehicles via wired networks such as Ethernet or fiber optics and wireless networks such as Mesh or IEEE 802.11b/g may be available. With network connectivity to the intersection, vehicle tracking information may be delivered over a network medium. In this instance, the vehicle location is either broadcast by the vehicle itself over the network or it may broadcast by an intermediary gateway on the network that bridges between, for example, a wireless medium used by the vehicle and a wired network on which the intersection electronics resides. In this case, the vehicle or an intermediary reports, via the network, the vehicle's security information, location, speed, and heading, along with the current time. Intersections on the network receive the vehicle information and evaluate the position using approach maps as described in the Opticom® GPS system. The security coding could be identical to the Opticom® GPS system or employ another coding scheme.
As used herein, the term “vehicle control unit” refers to the various types of modules capable of communicating a preemption request to a preemption controller. This includes, for example, IR light based modules, GPS based modules, and wireless network based modules. In addition, a preemption request refers to both preemption requests that emanate from emergency vehicles and to what are sometimes referred to as “priority requests,” which emanate from mass transit vehicles, for example.
The embodiments of the invention provide management of traffic signal preemption control equipment. In one embodiment, a method periodically reads logged preemption data from each of a plurality of intersections having respective preemption controllers for preempting traffic signals at the intersections. The logged preemption data at an intersection describes operational states of the preemption controller and each vehicle control unit that submitted a preemption request at the intersection and data describing each individual preemption request. The logged preemption data read from the plurality of intersections are stored in a database. The database is monitored for data indicative of changes in operational status of the traffic signal preemption control equipment. In response to the data indicating a change in operational status, data descriptive of the change are output.
In another embodiment, a system is provided for managing geographically dispersed traffic signal preemption control equipment. The system includes a processor and a memory arrangement coupled to the processor. The memory is configured with instructions for execution by the processor. The instructions include a first module for periodically reading logged preemption data stored at each of a plurality of intersections having respective preemption controllers for preempting traffic signals at the intersections. The first module stores the logged preemption data read from the plurality of intersections in a database in the memory arrangement. The logged preemption data describes operational characteristics of the preemption controller and each vehicle control unit that submitted a preemption request at the intersection and data describing each individual preemption request. A second module is provided for monitoring the database having the logged preemption data from the plurality of intersections for data indicative of changes in operational status of the traffic signal preemption control equipment. A third module is responsive to the data indicating a change in operational status. The third module outputs data for graphical display on a map of roadways and intersections. The data for graphical display includes graphical icons indicative of the operational status of the preemption control equipment at map locations corresponding to geographic locations of the preemption control equipment.
An article of manufacture is provided in another embodiment. The article of manufacture includes a processor-readable storage device configured with instructions for managing geographically dispersed traffic signal preemption control equipment. Executing the instructions by one or more processors causes the one or more processors to perform the operations including periodically reading logged preemption data stored at each of a plurality of intersections having respective preemption controllers for preempting traffic signals at the intersections. The logged preemption data at an intersection describes operational states of the preemption controller and each vehicle control unit that submitted a preemption request at the intersection and data describing each individual preemption request. The operations further include storing the logged preemption data read from the plurality of intersections in a database in an electronic storage device. The database having the logged preemption data from the plurality of intersections is monitored for data indicative of changes in operational status of the traffic signal preemption control equipment. In response to the data indicating a change in operational status, data descriptive of the change are output.
The above summary of the present invention is not intended to describe each disclosed embodiment of the present invention. The figures and detailed description that follow provide additional example embodiments and aspects of the present invention.
Each preemption controller logs preemption data that describe preemptions of the traffic signal and also stores data that describe the operational state of the preemption controller at an intersection. The data that describe preemptions include vehicle identifiers, dates and times of the start and end of the preemption request, the path of travel of the requesting vehicle, turn signal status, and preemption signal strength, for example.
Data stored at each preemption controller support maintenance of the controller. However, access to the data in prior systems was made by way of connecting a portable computer to the preemption controller at the intersection where the preemption controller was installed. Thus, periodic maintenance checks required travel to geographically dispersed traffic signal preemption control equipment and determining whether or not there was a maintenance issue to be addressed at that intersection. In addition, a gradual decline in preemption system performance was not readily apparent to service personnel when reviewing call history from a single intersection over a limited time period.
The various embodiments of the invention provide approaches for managing geographically dispersed traffic signal preemption controllers. Generally, preemption data logged at the intersections are periodically gathered by a centralized management system and the preemption data are monitored for equipment operating anomalies and misuse of the system. In one approach, a centralized management system operating on one or more computers, periodically reads logged preemption data stored by preemption controllers at each of a plurality of intersections. Along with data describing each individual preemption request, the logged preemption data at an intersection describes operational characteristics of the preemption controller and each vehicle control unit that submitted a preemption request at the intersection. The centralized management system stores the retrieved logged preemption data in a database and monitors the database for data indicative of changes in operational status of the traffic signal preemption control equipment. In response to the data indicating a change in operational status, the centralized management system outputs data descriptive of the change.
The traffic control preemption system shown in
In
The traffic signal controller determines the priority of each signal received and whether to preempt traffic control based on the security code contained in the signal. For example, the ambulance 20 may be given priority over the bus 22 since a human life may be at stake. Accordingly, the ambulance 20 would transmit a preemption request with a security code indicative of a high priority while the bus 20 would transmit a preemption request with a security code indicative of a low priority. The phase selector would discriminate between the low and high priority signals and request the traffic signal controller 14 to cause the traffic signal lights 12 controlling the ambulance's approach to the intersection to remain or become green and the traffic signal lights 12 controlling the bus's approach to the intersection to remain or become red.
When a preemption request is received, the phase selector (preemption controller) stores a record of the request in a preemption log. Each stored entry in the log includes preemption data such as: the emitter code of the requesting vehicle; the time and date of the request; the direction or approach from which the request was received; whether the request was granted; etc. This stored information can later be uploaded to a central management server and used to analyze preemption use and or generate reports. To assure correct operation of preemption control of each intersection, some embodiments store the status of the lights at the end of preemption control. The status indicates the direction in which traffic was preempted, which phases (straight or turn lanes) were green when preemption control ended, and the duration of that green state. This information can be compared at the central control server to determine if the preemption controller of the intersection is operating as expected.
The central management server 214 is additionally coupled to a database server 230. Code maps 232 contain respective sets of codes for the jurisdictions managed by the central management server 214 and are stored on server 230. A controller log database 234 is also stored on server 230. It is understood that database server 230 may comprise several local and/or remote servers.
The central management server 214 periodically gathers preemption data logged at the intersections, and the preemption data are monitored for equipment operating status, anomalies and misuse of the system. The preemption data are associatively stored in the controller log database 234. In one embodiment, each preemption controller 210 and 212 maintains a respective log file 242 and 244. The data stored in each log file describe each preemption request for the associated intersection. In one embodiment, the data include a vehicle control unit identifier, a date and time of the preemption request, and the duration of the preemption. The logged preemption data at an intersection further describe operational characteristics of the preemption controller and each vehicle control unit that submitted a preemption request at the intersection. This data include, for example, whether the preemption controller is operating normally, is offline, or is non-responsive. For vehicle control units, values describing the signal strength are stored for each preemption request. The signal strength may be used to identify maintenance issues for both vehicle control units and for preemption controllers.
The centralized management system monitors the database 234 for data indicative of changes in operational status of the traffic signal preemption control equipment. In response to the data indicating a change in operational status, the centralized management system outputs data descriptive of the change. In one embodiment, the status may be communicated by way of updating a display monitor 252. Other channels may be used to communicate the status information. For example, status information may be output and communicated via email messages, telephone or text messages, or electronic messages directed to other software applications.
In another embodiment, the central management server 214 monitors the database for data indicative of anomalies and reports such occurrences accordingly. Such anomalies include, for example, decreasing signal strength for a particular vehicle control unit or a particular preemption controller showing a lesser signal strength for all vehicle control units as compared to other preemption controllers. The data may indicate a particular vehicle control unit is in need of service or repair if the signal strength from that vehicle control unit is below a desired threshold as received and logged at multiple preemption controllers. The data may indicate that a preemption controller (or other receiving equipment) is in need of service or repair if the signal strengths from multiple vehicle control units as logged by that preemption controller are less than the signal strengths from those same vehicle control units as logged by other preemption controllers.
It is understood that numerous network transfer protocols may be used to establish, maintain, and route connections including: TCP/IP, UDP, NFS, ESP, SPX, etc. It is also understood that network transfer protocols may utilize one or more lower layers of protocol communication such as ATM, X.25, or MTP, and on various physical and wireless networks such as, Ethernet, ISDN, ADSL, SONET, IEEE 802.11, V.90/v92 analog transmission, etc.
At step 304, the retrieved data are stored in a database for subsequent retrieval and analysis using any of a variety of suitable database engines. At step 306, the data in the database are monitored for changes that indicate changes in operational state of the preemption control equipment. Such changes generally include newly added preemption requests, expired preemptions, status of vehicle control units, and status of preemption controllers, for example.
At step 308, a change in operational status is communicated by way of outputting data descriptive of the change. The data may be output to a display monitor on which a map of roads, intersections, vehicle icons, and preemption controller icons is displayed. The data may also or alternatively be communicated via other channels as described above.
Traffic signal icons 402, 404, and 406 are displayed at the intersections of Barranca & Culver, Barranca & Harvard, and Barranca & Marvin. A fire engine icon 408 is displayed at the intersection of Barranca & Park. Informational icons 410, 412, and 414 are displayed at the intersections of Alta & Culver, University & Culver, and Central & Culver.
Along with the icons, a tabular display of preemption controller data is presented in tables 422 and 424. Table 422 contains preemption log entries, and table 424 contains preemption controller status records.
Table 422 in
Table 424 in
In response to detecting a change in state or that a new preemption request has been received at step 554, the scheduling module stores the log data in the database at step 556. The log data stored in the database are supplemented with or associated with further data available on the server. The supplemental data include the name of the intersection from which the data were uploaded, a vehicle name associated with the vehicle control unit identifier, an agency name, or a jurisdiction name, for example.
The scheduling module also periodically reads extended configuration information from the preemption controllers and stores this data in the database. The clock in the preemption controller may be periodically set by the scheduling module to correct any clock drift.
In another embodiment, the preemption equipment may include vehicle control units that interface with wireless networks such as Mesh or IEEE 802.11b/g. The scheduler may be configured to directly poll those vehicle control units for identifier and location data in combination with polling the preemption controllers. The data received from the vehicle control units is supplemented and stored in the database as described above.
In another embodiment, the database monitor is configured to monitor the database for changes in location of one or more selected vehicles. This data may have been gathered by the scheduling module directly from vehicle control units. Changes in location may be reported as events to the map display module 506.
In response to an event reported by the database monitor, at step 656 the map display module reads related data from the database. For example, in response to a change in state of a preemption controller, the map display module reads the related intersection name from the database. For a new preemption, the map display module reads the vehicle name, vehicle control unit identifier (emitter number if
At step 658, the map display module updates the displayed map to reflect and describe the occurrence of the event. For a change in state of a preemption controller, the icon at an intersection may be changed to indicate whether the controller is normal, broken, or offline, for example. For a preemption, the map is updated to show a vehicle icon at the intersection at which the preemption occurred. The preemption log entry table 422 is updated to include entries for the new preemptions.
In another embodiment, the map display module registers with the database monitor to receive events that are based on location changes of vehicles that communicate directly with the scheduling module. The map display module displays vehicle icons on the map at locations corresponding to the reported locations.
At step 702, the module registers with the database monitor to receive reports of changes in operational status of preemption controllers and reports of new preemptions. In response to a reported event, at step 704 the module reads related data from the database.
For a preemption controller status event, the event report indicates an identifier of the preemption controller to the module. In response, the module reads the intersection name, communications channel, event severity (Info, Error, Warning), and associated event description data from the database.
For a new preemption event, the event report indicates an identifier of the preemption controller to the module. In response, the module reads the intersection name, direction of travel, vehicle name, vehicle's agency, vehicle code, vehicle priority, start time, preemption duration, green sense data, signal strength, turn single status, preemption granted, and vehicle authorized.
In an example embodiment, separate tables are displayed for preemption controller status data and new preemption data at step 706.
At step 742, the alerting module registers with the database monitor to receive reports of events. In response to receiving an event report, the alerting module forwards information describing the event to another software application at step 744 for further processing.
The data in the log files includes signal strength levels of vehicle control units making preemption requests as detected by the preemption controllers. At step 802, the performance monitor looks for reductions in signal strength that indicate those vehicle control units in need of repair or maintenance. For example, where the signal strength level of a particular vehicle control unit is below a certain threshold at multiple intersections, there is a strong possibility that the vehicle control unit is in need of repair. Since the signal strength levels are considered across multiple intersections, the likelihood of false positives may be reduced.
The vehicle control unit signal strength levels may also be used in determining that a preemption controller is in need of repair. For example, if the signal strength levels detected by a particular preemption controller for all the vehicle control units is below a certain threshold or mean of the signal strength levels is below a certain threshold, the data may indicate that the preemption controller is in need of maintenance or repair. At step 804, the performance monitor looks for reductions in signal strength of vehicle control units that point to a preemption controller needing repair or maintenance.
Misuse of preemption equipment may also be detected from the preemption log files at one or more intersections. Various patterns of preemption data may indicate the misuse. For example, if a particular vehicle control unit makes more than a threshold number of preemption requests in a certain period of time, misuse of the vehicle control unit may be indicated. Also, if a particular vehicle control unit makes preemption requests at the same intersection at approximately the same time each day for some number of days, misuse may be indicated. At step 806, the performance monitor looks for preemption data that is indicative of unauthorized use of the equipment.
Unauthorized use of the preemption equipment may also be detected from the preemption log files at one or more intersections. For each preemption request, the preemption log data includes the identifier of the vehicle control unit that made the request. The vehicle control unit identifier is transmitted in the request from the vehicle control unit to the preemption controller. At step 808, if the vehicle control unit has not been properly configured with an authorized identifier, some installations may consider the vehicle control unit to be unauthorized for use. For example, if the logged vehicle control unit identifier for a preemption is 0, the preemption may be deemed to have been unauthorized.
If one of the above-mentioned anomalies is detected, data is output to alert a traffic engineer of the occurrence anomaly at step 810.
Processor computing arrangement 850 includes one or more processors 852, a clock signal generator 854, a memory unit 856, a storage unit 858, a network adapter 864, and an input/output control unit 860 coupled to host bus 862. The arrangement 850 may be implemented with separate components on a circuit board or may be implemented internally within an integrated circuit.
The architecture of the computing arrangement depends on implementation requirements as would be recognized by those skilled in the art. The processor 852 may be one or more general purpose processors, or a combination of one or more general purpose processors and suitable co-processors, or one or more specialized processors (e.g., RISC, CISC, pipelined, etc.).
The memory arrangement 856 typically includes multiple levels of cache memory and a main memory. The storage arrangement 858 may include local and/or remote persistent storage such as provided by magnetic disks (not shown), flash, EPROM, or other non-volatile data storage. The storage unit may be read or read/write capable. Further, the memory 856 and storage 858 may be combined in a single arrangement.
The processor arrangement 852 executes the software in storage 858 and/or memory 856 arrangements, reads data from and stores data to the storage 858 and/or memory 856 arrangements, and communicates with external devices through the input/output control arrangement 860 and network adapter 864. These functions are synchronized by the clock signal generator 854. The resources of the computing arrangement may be managed by either an operating system (not shown), or a hardware control unit (not shown).
The present invention is thought to be applicable to a variety of systems for a preemption controller. Other aspects and embodiments of the present invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and illustrated embodiments be considered as examples only, with a true scope and spirit of the invention being indicated by the following claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4914434 | Morgan et al. | Apr 1990 | A |
| 5014052 | Obeck | May 1991 | A |
| 5172113 | Hamer | Dec 1992 | A |
| 5187476 | Hamer | Feb 1993 | A |
| 5202683 | Hamer et al. | Apr 1993 | A |
| 5406615 | Miller et al. | Apr 1995 | A |
| 5539398 | Hall et al. | Jul 1996 | A |
| 5602739 | Haagenstad et al. | Feb 1997 | A |
| 5955968 | Bentrott et al. | Sep 1999 | A |
| 5973616 | Grebe et al. | Oct 1999 | A |
| 6064319 | Matta | May 2000 | A |
| 6985090 | Ebner et al. | Jan 2006 | B2 |
| 7307547 | Schwartz | Dec 2007 | B2 |
| 7333028 | Schwartz | Feb 2008 | B2 |
| 7417560 | Schwartz | Aug 2008 | B2 |
| 20030128135 | Poltorak | Jul 2003 | A1 |
| 20050104745 | Bachelder et al. | May 2005 | A1 |
| 20080316055 | Bachelder et al. | Dec 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| WO 2005094544 | Oct 2005 | WO |
| WO 2006115756 | Apr 2006 | WO |
| WO 2006130633 | Dec 2006 | WO |
| WO 2006138364 | Dec 2006 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20110193722 A1 | Aug 2011 | US |
