Arthur J. Dock
GPS and ArcView can be used together to quickly test emergency vehicle traffic signal preemption equipment. This paper describes a step-by-step testing method developed by the author. Preemption provides priority treatment by interrupting the normal cycling of a traffic signal in favor of an emergency vehicle. This assists emergency personnel in safe and timely arrival at incidents. The range setting of these devices is critical, as the traffic signal must have an adequate amount of time to display the appropriate indications. Testing provides verification of range.
Preemption provides priority treatment interrupting the normal cycling of a traffic signal in favor of an emergency vehicle. Mesa, and many other jurisdictions, use systems based on optical communication. These systems are line-of-site and have a limited and adjustable range. The traffic signal must detect the approach of the emergency vehicle sufficiently in advance of its arrival. This is because the signal has to cycle through any necessary timing intervals and arrive at the desired signal display before the emergency vehicle is at the intersection. The range setting of preemption equipment is therefore critical for proper operation.
Range setting is a normal part of equipment installation and my be checked from time-to-time during maintenance. Range is typically set by driving some distance from the intersection (e.g. 3/10 of a mile) and transmitting a special range setting code (as a security measure, the unit in the signal cabinet must be powered off/on to initiate a timeout period in which to perform the range setting operation). Verification of range settings typically involves one person at the cabinet observing that the preempt call is received while another person in a vehicle drives (preempts) the intersection. Testing done in this manner may or may not actually preempt the intersection as the technician at the cabinet may disconnect the preemption equipment from the traffic signal controller during the test. Disconnecting the equipment avoids unnecessary disruption of traffic, however, this does not provide a complete test of the signal operation (e.g. testing the signal controller programming: assuring that the signal responds with the correct display before arrival at the intersection).
Mesa's entire preemption system has not been tested on a regular scheduled basis. Part of the problem involves the number of preemption equipped signalized intersections and the amount of time involved with implementing a full testing operation. On average it is estimated to take one hour for two persons to test all directions at an intersection. As of June 2002, Mesa has 202 preempt equipped traffic signals which would require in the neighborhood of 400 hours to test. This number, of course, will only increase as the number of preemption equipped intersections is increased by 12 to 16 each year.
This was our dilemma. A critical system needed to be tested but testing was not practical utilizing "standard" methods. A better way needed to be found.
Another way of doing this was and is possible. The basic idea is alluring and simple. A vehicle equipped with a preemption emitter can capture its Position, Velocity, and Time (PVT) data with a Global Positioning System (GPS) receiver unit. The vehicle is simply driven around the city at an off-peak time (e.g. early Sunday AM) to each approach of each preemption equipped traffic signal. Back at the office, the PVT data can be correlated with actual preemption events captured by the traffic signal equipment and a distance report can be generated. Besides being faster, this also provides a reliable, documented, and repeatable method.
The way this works is also simple... if the following things can be determined for the exact second that a preempt event occurs:
The vehicle position and time are captured by the GPS unit and the position of the signals (center of signalized intersection) are known from the existing GIS data. However, bringing these bits of information together takes a bit of work because of the multiple systems involved and conversion of data to common (compatible) formats. If anything can be both convoluted yet straightforward this is it.
Some technology is required for this task.
In Mesa the following mapping issues have to be be dealt with:
But...
These differences mean that GPS data cannot simply be placed onto the City's maps without a datum conversion and projection. This issue is solved at present by converting the GPS collected data points to NAD 27 State Plane Arizona Central using tools available through Esri ArcView 3.2 or ArcGIS 8.2
The City of Mesa currently has two traffic signal control systems. The time base of both systems as well as the GPS unit must be correlated. So, what time is it?
But...
And...
UTC time does not match GPS time. At present, GPS time is 13 seconds ahead (e.g. if GPS = 12:00:00 then UTC = 11:59:47). This time difference will vary further in the future as additional leap-seconds are added to UTC since GPS does not add leap seconds. As it turns out, the GPS-based clock the newer system is using still delivers UTC time to the system. Both systems, therefore, are running on UTC. Since the GPS unit captures leap second information from the satellite data stream and passes this information along, conversion of any GPS times to UTC can be done by deducting the current leap seconds value. UTC it is.
However, since time is such a critical component of this process there are additional adjustments beyond the basic UTC vs. GPS time issue. The following further realities must be accounted for in adjusting the collected time data:
* Nyquist (sampling theory) states that we cannot reliably see any event of less that 2 second duration given a once per second polling rate. The polling period on the new system is typically once per second (maybe faster, maybe slower). The exact polling rate can vary depending on numerous variables (e.g. objects being transmitted, number of drops on the line, modem type, secondary messages, and etc). The event log time is based on when the system's event logger saw the event pass through the central system's event channel. In reality, the second that an event is logged in will be the first one after the event occurs (e.g. the system polls = no event, event occurs, system polls = event). Rounding off and deducting a second is reasonable in this case.
Despite the apparently complex reality, through experimentation and looking at the actual data it has been determined as follows:
This simple view should be adequate for most testing purposes. If more accuracy is desired, it is possible to verify that time at intersections on either traffic control system. Unfortunately, however, this must be done in the same time-frame as the testing since both systems implement daily time downloads and do not log time inaccuracy. Since both systems automatically download the current time every day in the early hours of the morning, accurate time is another benefit of doing testing early in the day (i.e. less/less-likely field unit time drift early in the day).
Accuracy is by no means absolute. However, by taking into consideration the variables involved, a reasonable estimate of plus/minus values can be calculated on an event-by-event basis. In any case, it can be expected that the accuracy achieved will exceed some other techniques (e.g. two-man manual field testing using a vehicle odometer as a distance gauge).
Accuracy is affected by the following (and possibly other) things:
The question becomes what level of accuracy is acceptable? The absolute maximum range of the actual preemption equipment varies due to a number of factors. Older generation equipment from one manufacturer states a maximum 1,800 foot range whereas their newer product claims a maximum of 2,500 foot range. This is their specified typical range, which may be (and is) often exceeded in reality. Mesa, for example, has both older 1,800 foot and newer 2,500 foot types of equipment. For comparison and confirmation purposes, on July 18, 2001 a parallel test was conducted. The range of an intersection was set using the odometer as a rough guide for 3/10 of a mile. The position was simultaneously captured using GPS and later compared. The GPS data showed the set range to be 1,320 feet (as opposed to the expected 1,584). The error in this case resulted in a setting that was 16.7% low (meaning less time to preempt the signal than expected). Certainly the level of accuracy of traditional testing can be exceeded.
The main purpose of this testing method is to provide a quick way to spot locations which are noticeably out of specification. Given the factors involved, the following reasonable conservative error estimates are offered:
These ranges will be further offset by any GPS and GIS errors. For example, a test consisting of 1,704 data points showed eph (estimated horizontal error) ranging from 8.44 to 31.56 with a mean average of 12.57 feet. Assuming a +/- 10 foot error for the GIS maps and taking the worst-case for the eph results in a basic GPS to GIS error of +/- 41.56 feet. Being further conservative and rounding up to +/- 48 feet results in a nice round overall error of +/- 180 feet or +/-11.36% of 1,584 feet which compares favorably to the -16.7% observed in one real world case. GPS could, of course, be used with the old testing method instead of the odometer to greatly improve upon the 16.7% error: however, that would take significant time which is the whole point of this exercise: saving time while achieving acceptable results.
Also note that driving slower will improve the accuracy of the test (i.e. not as much vehicle position change second-by-second) although this will take more time. A good compromise might be to just slow down at approximately the expected range of the preemption equipment (e.g. the last 2,000 feet or so before the intersection) to gain a more accurate result. This could further be augmented by using a mobile connection to the traffic control system to verify when the preempt is received and then resuming speed at that time. Normally, however, testing has been done at the posted speed limit.
Note that the discussion above doesn't even touch on the basic optical system which has unqauntified variations (although speculative numbers have been provided to the author verbally by manufacturers). These may be significant (e.g. a new emitter strobe lamp vs. one with a high number of hours) but are not taken into account. Reality may not an absolute in this case but we can proceed based on what we do know.
How is this accomplished? The basic step-by-step process is shown below.
1. Create preempt events and capture GPS PVT data.
This is done by driving around in a City vehicle with an operating preemption emitter. The vehicle is also equipped with a GPS unit and laptop PC Host capturing the GPS data second-by-second. Since the intersections are actually preempted, it is recommended that this be done during off-peak times such as early Sunday morning (testing in Mesa has been done on Sundays from approximately 3:30 am to 6:00 am).
2. Convert the GPS PVT data to match the City's GIS.
Since the GPS data is in WGS 84 decimal degrees, it must be converted to NAD 27 State Plane Arizona Central feet to be used on the City's GIS. This is done inside ArcView 3.2 using the "NADCON" and "Projector!" utilities (or within ArcGIS 8.2).
3. Gather traffic signal control system event logs.
Each of the two systems involved stores its data in a unique format. This step involves retrieving preempt start event data from a logging terminal on the older system and from the file server on the newer system. These events are merged into a single table and have their time adjusted to match UTC.
4. Match PVT data to signal system events creating a preempt data table.
A new data table is created that matches the PVT data to its related system event (i.e. which signal was preempted). The table also contains the position of the signalized intersection retrieved from an existing GIS database.
5. Calculate the distance.
Since the location of the vehicle was calculated in step 2 and the location of the intersection was retrieved in step 4, all that remains to do is a simple calculation of the distance.
6. Generate reports, use, and analyze the data.
A fully detailed explanation of each of the above listed steps are shown below.
The PVT data capture program is a Visual BASIC application that logs the following data from the GPS to a file:
Name |
Type |
Description |
| tow | double | Time of week: seconds (excluding leap) since Sunday 12:00 AM. |
| leap_scnds | integer | Leap seconds: subtract this value from .tow to find UTC. |
| wn_days | long integer | Days since UTC December 31, 1989. |
| lat | double | Latitude WGS84 decimal degrees. |
| lon | double | Longitude WGS84 decimal degrees. |
| msl_hght | single | Mean sea level height WGS84 in feet. |
| alt | single | Altitude above WGS84 ellipsoid in feet. |
| east | single | Velocity east in feet/second. |
| north | single | Velocity north in feet/second. |
| up | single | Velocity up in feet/second. |
| epe | single | Overall [E]stimated [P]ositional [E]rror in feet. |
| eph | single | Horizontal positional error in feet. |
| epv | single | Vertical positional error in feet. |
| pfix | integer | Type of position fix (see tblPFix for list). |
NOTES:
| ID | Description |
| 0 | unusable - failed integrity test. |
| 1 | invalid - invalid or unavailable. |
| 2 | 2D - two dimensional. |
| 3 | 3D - three dimensional. |
| 4 | 2D_diff - two dimensional differential. |
| 5 | 3D_diff - three dimensional differential. |
The GPS data is stored in a database that contains additional fields:
| Name | Type | Description |
| second | long integer | Number of seconds since January 1, 2001 |
| vx | double | Vehicle easting (projected longitude). |
| vy | double | Vehicle northing (projected latitude). |
Since there is a limitation (in Microsoft Access and possibly other databases) regarding relating tables based on a date/time (date/time is actually stored as a double precision number), a conversion is necessary. The UTC time needs to be stored in another field as the number of seconds from some given (arbitrary) date/time. This is done with a query that sets the [second] field to the formula below (using the millennial epoch):
DateDiff("s",#01/01/2001#,[When])
Another fact of life is that the GPS system can skip seconds. It may be necessary to interpolate and create entries for the missing seconds. The values stored in any manufactured (interpolated) records consist of the values in between the records before and after the missing data. This may be done manually or with a special utility. To save time it can be advantageous to try relate the PVT data to the preempt events first and see if any records were "missed" and then create interpolated records only if necessary.
Since the GPS data is in WGS 84 decimal degrees, it must be converted to NAD 27 State Plane Arizona Central feet to be used with the City of Mesa's GIS data. This can be done inside ArcView 3.2 using the "NADCON" and "Projector!" utilities (or within ArcGIS 8.2). Detailed step-by-step directions for this task are in convert.doc available from the author. Essentially converting from GPS to NAD 27 State Plane Arizona Central in ArcView 3.2 consists the following:
Each of the two systems involved stores its data in a unique format. This step involves retrieving preempt start event data from a logging terminal on the older system and from the file server on the newer system. These events are merged into a single table and have their time adjusted to match UTC.
NOTE: In both systems event text files are only available one day after the date of interest. For example, July 29th's logs cannot be retrieved until July 30th or later (unless using the report generator under "Sonex" (providing a different data format) or accessing the SQL server with ODBC for the "icons" system.
First, the older ("Sonex") system:
Next, the newer ("icons") system:
The event logs from each system are typically several thousand records per day. To make the comparison easier (and the dataset smaller), the preempt events are filtered out from the two separate systems and merged into a single data table (tblPreempt) consisting of the following:
| Field | Type | Description |
| timestamp | Date/Time | UTC date/time of event occurrence |
| second | Long Integer | Number of seconds since January 1, 2001 |
| system | Text * 5 | "Sonex" or "icons" |
| intersection | Integer | Intersection number (e.g. 1250) |
| mnemonic | Text * 5 | Intersection mnemonic shortname (e.g. "BN-MD") |
| event | Text * 100 | System event (e.g. "PREEMPT OPTIC START") |
| ix | Double | Intersection easting (projected longitude). |
| iy | Double | Intersection northing (projected latitude). |
Since there is a limitation (in Microsoft Access and possibly other databases) regarding relating tables based on a date/time, a conversion is necessary. The UTC time needs to be stored in another field as the number of seconds from some given (arbitrary) date/time. This is done with a query that sets the [second] field to the formula below (using the millennial epoch):
DateDiff("s",#01/01/2001#,[timestamp])
At this point there are two key data tables. The first table (tblGPS) contains the data points collected from the GPS. The second table (tblPreempt) contains the preempt events from the traffic control systems. The next step is to merge these two tables into another table that shows only the preempt events that have matching GPS data as well as the position of the signalized intersection retrieved from an existing GIS database.
This process involves some sub-steps.
a). Relate tblPreempt to the intersection list to retrieve the position of the signalized intersection. This value is retrieved from the [x] and [y] fields from the inventory system tblLocation and is stored in the [ix] and [iy] fields.
b). The tblGPS data must be retrieved from the dBase (dbf) file that has been converted and projected by ArcView. Since the only thing of interest are the [x] and [y] fields, these may be retrieved by attaching the dBase file and then running an update query to pull these values into the tblGPS [x] and [y] fields. However, if there are many data points Access may not successfully be able to relate them (too much data). In that case, relate the ArcView data to the actual preempts (tblPreempt) instead of the whole GPS dataset contained in tblGPS (e.g. 700 records vs. 39,000 records).
c). Now both tblPreempt and tblGPS are complete, ready to relate, and contain the following information:
d). The distance dataset (tblDistance) is created by relating tblGPS and tblPreempt using the [second] field (number of seconds since 01/01/2001). A simple create table query accomplishes this.
There are additional fields in tblDistance that were not in either tblGPS or tblPreempt::
| Name | Type | Description |
| distance | double | Distance from vehicle to intersection in feet. |
| bogus | boolean | Entry is valid yes/no. |
Distance is calculated by a query that sets [distance] equal to the formula below:
abs(sqr(((vx - ix)^2) + ((vy - iy)^2)))
where:
vx = vehicle easting
vy = vehicle northing
ix = intersection easting
iy = intersection northing
The [bogus] field exists because it is possible to have a GPS point match with a non-related preempt event (e.g. a fire truck preempts another signal the exact same second that a test is being run in another part of town). This type of error will show up as an overly large range value and on any maps as a position fix extremely far from the intersection associated by the preempt time relationship. These occurrences are weeded out by setting the [bogus] field to True for inappropriate [range] values (e.g. [range] > 5,280).
Once the distance has been calculated, it is now possible to use the data to find locations which do not meet specs by simply sorting the data table by distance. It is also very easy to run statistical analysis on the distance data in numerous useful ways (e.g. min, max, average, and etc.). If one is so inclined, since the GPS stores health information (e.g. [epe], [evh], [epv], [pfix], etc.) it is possible to create an estimated error for each point. In fact, it is recommended that as a minimum quality control measure that the [pfix] be verified that it is NOT 0 or 1 (invalid or unusable).
By exporting tblDistance to dBase and using ArcView to create event themes from it many useful maps can be created. For example, the following event themes are a good starting point:
The first stages of developing this process were started in mid-2001. Testing began by running twelve traffic signal approaches on two occasions (July 29, 2001 and September 2, 2001) and comparing results. Subsequently, this has been followed up by real-world usage of the system. As of June 2002, 354 out of 722 approaches have been tested. To accomplish this, the driving time for three sessions (as logged by the GPS) was 8 hours 10 minutes. Based on these numbers the following estimate for complete system testing (compare with the 400+ hour estimate for traditional testing) is offered:
| Description | Hours |
| Driving preparation (30 minutes each drive) | 3.0 |
| Driving | 16.5 |
| Processing | 12.0 |
| Total Hours | 31.5 |
|---|
Additional features have been added to the dataset and are now being utilized:
As an additional benefit, this testing method has resulted in the discovery of configuration as well as programming issues involving the traffic signal equipment in the field which had not otherwise been noticed or reported by system maintainers or users.
This testing has resulted in additional innovation. To aid field crews in setting up the initial range for the equipment, the City of Mesa signal inventory system has a new feature. The system can download the coordinates of selected intersections to a GPS unit as waypoints using NMEA (National Marine Electronics Association) protocol. Typical hand-held GPS units can display the distance to a selected waypoint. Using this feature allows the technician to achieve a much more accurate range setting than would be possible, for example, using the vehicle odometer as a distance gauge.
Preemption is a useful tool for emergency personnel and as such needs to be maintained in a ready-to-go state. Testing this system has traditionally been a time-consuming proposition and therefore not a routine process. Utilizing GPS/GIS results in a very efficient and repeatable method of testing that can actually be done.
For questions or comments regarding this paper please email arthur_dock@ci.mesa.az.us
Arthur J. Dock
Signal Systems Analyst
City of Mesa, Arizona