**Published...**

  ----------------------------------------------------- ----------------------- ----------------------------------------------------
  ![](media/image1.jpeg){width="1.8541666666666667in"   FTA-NJ-26-7062-06.1     ![](media/image2.png){width="1.6909722222222223in"
  height="1.3333333333333333in"}                                                height="1.3069444444444445in"}

  ----------------------------------------------------- ----------------------- ----------------------------------------------------

**ADVANCED PUBLIC**

**TRANSPORTATION SYSTEMS:**

**THE STATE OF THE ART**

**UPDATE 2006**

![](media/image3.jpeg){width="6.496527777777778in"
height="3.613888888888889in"}

![](media/image4.png){width="1.1770833333333333in"
height="1.1770833333333333in"}

+------------+-----+-----------+-----------+---+---+------------------+
| # REPOR    |     |           |           | * |   |                  |
| T DOCUMENT |     |           |           | F |   |                  |
| ATION PAGE |     |           |           | o |   |                  |
|            |     |           |           | r |   |                  |
|            |     |           |           | m |   |                  |
|            |     |           |           | A |   |                  |
|            |     |           |           | p |   |                  |
|            |     |           |           | p |   |                  |
|            |     |           |           | r |   |                  |
|            |     |           |           | o |   |                  |
|            |     |           |           | v |   |                  |
|            |     |           |           | e |   |                  |
|            |     |           |           | d |   |                  |
|            |     |           |           | * |   |                  |
|            |     |           |           |   |   |                  |
|            |     |           |           | * |   |                  |
|            |     |           |           | O |   |                  |
|            |     |           |           | M |   |                  |
|            |     |           |           | B |   |                  |
|            |     |           |           | N |   |                  |
|            |     |           |           | o |   |                  |
|            |     |           |           | . |   |                  |
|            |     |           |           | 0 |   |                  |
|            |     |           |           | 7 |   |                  |
|            |     |           |           | 0 |   |                  |
|            |     |           |           | 4 |   |                  |
|            |     |           |           | - |   |                  |
|            |     |           |           | 0 |   |                  |
|            |     |           |           | 1 |   |                  |
|            |     |           |           | 8 |   |                  |
|            |     |           |           | 8 |   |                  |
|            |     |           |           | * |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| Public     |     |           |           |   |   |                  |
| reporting  |     |           |           |   |   |                  |
| burden for |     |           |           |   |   |                  |
| this       |     |           |           |   |   |                  |
| collection |     |           |           |   |   |                  |
| of         |     |           |           |   |   |                  |
| i          |     |           |           |   |   |                  |
| nformation |     |           |           |   |   |                  |
| is         |     |           |           |   |   |                  |
| estimated  |     |           |           |   |   |                  |
| to average |     |           |           |   |   |                  |
| 1 hour per |     |           |           |   |   |                  |
| response,  |     |           |           |   |   |                  |
| including  |     |           |           |   |   |                  |
| the time   |     |           |           |   |   |                  |
| for        |     |           |           |   |   |                  |
| reviewing  |     |           |           |   |   |                  |
| ins        |     |           |           |   |   |                  |
| tructions, |     |           |           |   |   |                  |
| searching  |     |           |           |   |   |                  |
| existing   |     |           |           |   |   |                  |
| data       |     |           |           |   |   |                  |
| sources,   |     |           |           |   |   |                  |
| gathering  |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| m          |     |           |           |   |   |                  |
| aintaining |     |           |           |   |   |                  |
| the data   |     |           |           |   |   |                  |
| needed,    |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| completing |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| reviewing  |     |           |           |   |   |                  |
| the        |     |           |           |   |   |                  |
| collection |     |           |           |   |   |                  |
| of         |     |           |           |   |   |                  |
| in         |     |           |           |   |   |                  |
| formation. |     |           |           |   |   |                  |
| Send       |     |           |           |   |   |                  |
| comments   |     |           |           |   |   |                  |
| regarding  |     |           |           |   |   |                  |
| this       |     |           |           |   |   |                  |
| burden     |     |           |           |   |   |                  |
| estimate   |     |           |           |   |   |                  |
| or any     |     |           |           |   |   |                  |
| other      |     |           |           |   |   |                  |
| aspect of  |     |           |           |   |   |                  |
| this       |     |           |           |   |   |                  |
| collection |     |           |           |   |   |                  |
| of         |     |           |           |   |   |                  |
| in         |     |           |           |   |   |                  |
| formation, |     |           |           |   |   |                  |
| including  |     |           |           |   |   |                  |
| s          |     |           |           |   |   |                  |
| uggestions |     |           |           |   |   |                  |
| for        |     |           |           |   |   |                  |
| reducing   |     |           |           |   |   |                  |
| this       |     |           |           |   |   |                  |
| burden, to |     |           |           |   |   |                  |
| Washington |     |           |           |   |   |                  |
| He         |     |           |           |   |   |                  |
| adquarters |     |           |           |   |   |                  |
| Services,  |     |           |           |   |   |                  |
| D          |     |           |           |   |   |                  |
| irectorate |     |           |           |   |   |                  |
| for        |     |           |           |   |   |                  |
| I          |     |           |           |   |   |                  |
| nformation |     |           |           |   |   |                  |
| Operations |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| Reports,   |     |           |           |   |   |                  |
| 1215       |     |           |           |   |   |                  |
| Jefferson  |     |           |           |   |   |                  |
| Davis      |     |           |           |   |   |                  |
| Highway,   |     |           |           |   |   |                  |
| Suite      |     |           |           |   |   |                  |
| 1204,      |     |           |           |   |   |                  |
| Arlington, |     |           |           |   |   |                  |
| VA         |     |           |           |   |   |                  |
| 2          |     |           |           |   |   |                  |
| 2202-4302, |     |           |           |   |   |                  |
| and to the |     |           |           |   |   |                  |
| Office of  |     |           |           |   |   |                  |
| Management |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| Budget,    |     |           |           |   |   |                  |
| Paperwork  |     |           |           |   |   |                  |
| Reduction  |     |           |           |   |   |                  |
| Project    |     |           |           |   |   |                  |
| (0         |     |           |           |   |   |                  |
| 704-0188), |     |           |           |   |   |                  |
| W          |     |           |           |   |   |                  |
| ashington, |     |           |           |   |   |                  |
| DC 20503.  |     |           |           |   |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 1\. AGENCY |     | 2\.       |           | 3 |   |                  |
| USE ONLY   |     | REPORT    |           | \ |   |                  |
| (Leave     |     | DATE      |           | . |   |                  |
| blank)     |     |           |           | R |   |                  |
|            |     | March 30, |           | E |   |                  |
|            |     | 2006      |           | P |   |                  |
|            |     |           |           | O |   |                  |
|            |     |           |           | R |   |                  |
|            |     |           |           | T |   |                  |
|            |     |           |           | T |   |                  |
|            |     |           |           | Y |   |                  |
|            |     |           |           | P |   |                  |
|            |     |           |           | E |   |                  |
|            |     |           |           | A |   |                  |
|            |     |           |           | N |   |                  |
|            |     |           |           | D |   |                  |
|            |     |           |           | D |   |                  |
|            |     |           |           | A |   |                  |
|            |     |           |           | T |   |                  |
|            |     |           |           | E |   |                  |
|            |     |           |           | S |   |                  |
|            |     |           |           | C |   |                  |
|            |     |           |           | O |   |                  |
|            |     |           |           | V |   |                  |
|            |     |           |           | E |   |                  |
|            |     |           |           | R |   |                  |
|            |     |           |           | E |   |                  |
|            |     |           |           | D |   |                  |
|            |     |           |           |   |   |                  |
|            |     |           |           | F |   |                  |
|            |     |           |           | i |   |                  |
|            |     |           |           | n |   |                  |
|            |     |           |           | a |   |                  |
|            |     |           |           | l |   |                  |
|            |     |           |           | R |   |                  |
|            |     |           |           | e |   |                  |
|            |     |           |           | p |   |                  |
|            |     |           |           | o |   |                  |
|            |     |           |           | r |   |                  |
|            |     |           |           | t |   |                  |
|            |     |           |           | N |   |                  |
|            |     |           |           | o |   |                  |
|            |     |           |           | v |   |                  |
|            |     |           |           | . |   |                  |
|            |     |           |           | 2 |   |                  |
|            |     |           |           | 0 |   |                  |
|            |     |           |           | 0 |   |                  |
|            |     |           |           | 4 |   |                  |
|            |     |           |           | - |   |                  |
|            |     |           |           | - |   |                  |
|            |     |           |           | M |   |                  |
|            |     |           |           | a |   |                  |
|            |     |           |           | r |   |                  |
|            |     |           |           | . |   |                  |
|            |     |           |           | 2 |   |                  |
|            |     |           |           | 0 |   |                  |
|            |     |           |           | 0 |   |                  |
|            |     |           |           | 6 |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 4\. TITLE  |     |           |           |   | 5 |                  |
| AND        |     |           |           |   | \ |                  |
| SUBTITLE   |     |           |           |   | . |                  |
|            |     |           |           |   | F |                  |
| Advanced   |     |           |           |   | U |                  |
| Public     |     |           |           |   | N |                  |
| Tran       |     |           |           |   | D |                  |
| sportation |     |           |           |   | I |                  |
| Systems:   |     |           |           |   | N |                  |
| State of   |     |           |           |   | G |                  |
| the Art    |     |           |           |   | N |                  |
| Update     |     |           |           |   | U |                  |
| 2006       |     |           |           |   | M |                  |
|            |     |           |           |   | B |                  |
|            |     |           |           |   | E |                  |
|            |     |           |           |   | R |                  |
|            |     |           |           |   | S |                  |
|            |     |           |           |   |   |                  |
|            |     |           |           |   | D |                  |
|            |     |           |           |   | T |                  |
|            |     |           |           |   | F |                  |
|            |     |           |           |   | T |                  |
|            |     |           |           |   | 6 |                  |
|            |     |           |           |   | 0 |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | 9 |                  |
|            |     |           |           |   | 9 |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | D |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | 4 |                  |
|            |     |           |           |   | 1 |                  |
|            |     |           |           |   | 0 |                  |
|            |     |           |           |   | 1 |                  |
|            |     |           |           |   | 5 |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 6\.        |     |           |           |   |   |                  |
| AUTHOR(S)  |     |           |           |   |   |                  |
|            |     |           |           |   |   |                  |
| Mimi       |     |           |           |   |   |                  |
| Hwang,     |     |           |           |   |   |                  |
| James      |     |           |           |   |   |                  |
| Kemp, Eva  |     |           |           |   |   |                  |
| L          |     |           |           |   |   |                  |
| erner-Lam, |     |           |           |   |   |                  |
| Nancy      |     |           |           |   |   |                  |
| Neuerburg, |     |           |           |   |   |                  |
| Paula      |     |           |           |   |   |                  |
| Okunieff;  |     |           |           |   |   |                  |
| edited by  |     |           |           |   |   |                  |
| John       |     |           |           |   |   |                  |
| Schiavone  |     |           |           |   |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 7\.        |     |           |           |   | 8 |                  |
| PERFORMING |     |           |           |   | \ |                  |
| OR         |     |           |           |   | . |                  |
| GANIZATION |     |           |           |   | P |                  |
| NAME(S)    |     |           |           |   | E |                  |
| AND        |     |           |           |   | R |                  |
| A          |     |           |           |   | F |                  |
| DDRESS(ES) |     |           |           |   | O |                  |
|            |     |           |           |   | R |                  |
| Palisades  |     |           |           |   | M |                  |
| Omni Team  |     |           |           |   | I |                  |
|            |     |           |           |   | N |                  |
| 91 West    |     |           |           |   | G |                  |
| Clinton    |     |           |           |   | O |                  |
| Avenue     |     |           |           |   | R |                  |
| Suite 2    |     |           |           |   | G |                  |
|            |     |           |           |   | A |                  |
| Tenafly,   |     |           |           |   | N |                  |
| NJ 07670   |     |           |           |   | I |                  |
|            |     |           |           |   | Z |                  |
|            |     |           |           |   | A |                  |
|            |     |           |           |   | T |                  |
|            |     |           |           |   | I |                  |
|            |     |           |           |   | O |                  |
|            |     |           |           |   | N |                  |
|            |     |           |           |   | R |                  |
|            |     |           |           |   | E |                  |
|            |     |           |           |   | P |                  |
|            |     |           |           |   | O |                  |
|            |     |           |           |   | R |                  |
|            |     |           |           |   | T |                  |
|            |     |           |           |   | N |                  |
|            |     |           |           |   | U |                  |
|            |     |           |           |   | M |                  |
|            |     |           |           |   | B |                  |
|            |     |           |           |   | E |                  |
|            |     |           |           |   | R |                  |
|            |     |           |           |   |   |                  |
|            |     |           |           |   | F |                  |
|            |     |           |           |   | T |                  |
|            |     |           |           |   | A |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | N |                  |
|            |     |           |           |   | J |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | 2 |                  |
|            |     |           |           |   | 6 |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | 7 |                  |
|            |     |           |           |   | 0 |                  |
|            |     |           |           |   | 6 |                  |
|            |     |           |           |   | 2 |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | 0 |                  |
|            |     |           |           |   | 6 |                  |
|            |     |           |           |   | . |                  |
|            |     |           |           |   | 1 |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 9\.        |     |           |           |   | 1 |                  |
| S          |     |           |           |   | 0 |                  |
| PONSORING/ |     |           |           |   | \ |                  |
| MONITORING |     |           |           |   | . |                  |
| AGENCY     |     |           |           |   | S |                  |
| NAME(S)    |     |           |           |   | P |                  |
| AND        |     |           |           |   | O |                  |
| A          |     |           |           |   | N |                  |
| DDRESS(ES) |     |           |           |   | S |                  |
|            |     |           |           |   | O |                  |
| Office of  |     |           |           |   | R |                  |
| Mobility   |     |           |           |   | I |                  |
| I          |     |           |           |   | N |                  |
| nnovation, |     |           |           |   | G |                  |
| TRI-11     |     |           |           |   | / |                  |
|            |     |           |           |   | M |                  |
| Federal    |     |           |           |   | O |                  |
| Transit    |     |           |           |   | N |                  |
| Admi       |     |           |           |   | I |                  |
| nistration |     |           |           |   | T |                  |
|            |     |           |           |   | O |                  |
| U.S.       |     |           |           |   | R |                  |
| Department |     |           |           |   | I |                  |
| of         |     |           |           |   | N |                  |
| Tran       |     |           |           |   | G |                  |
| sportation |     |           |           |   | \ |                  |
|            |     |           |           |   | A |                  |
| 400        |     |           |           |   | G |                  |
| Seventh    |     |           |           |   | E |                  |
| Street,    |     |           |           |   | N |                  |
| SW., Room  |     |           |           |   | C |                  |
| 9402       |     |           |           |   | Y |                  |
|            |     |           |           |   | R |                  |
| W          |     |           |           |   | E |                  |
| ashington, |     |           |           |   | P |                  |
| D.C. 20590 |     |           |           |   | O |                  |
|            |     |           |           |   | R |                  |
|            |     |           |           |   | T |                  |
|            |     |           |           |   | N |                  |
|            |     |           |           |   | U |                  |
|            |     |           |           |   | M |                  |
|            |     |           |           |   | B |                  |
|            |     |           |           |   | E |                  |
|            |     |           |           |   | R |                  |
|            |     |           |           |   |   |                  |
|            |     |           |           |   | T |                  |
|            |     |           |           |   | R |                  |
|            |     |           |           |   | I |                  |
|            |     |           |           |   | - |                  |
|            |     |           |           |   | 1 |                  |
|            |     |           |           |   | 1 |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 11\.       |     |           |           |   |   |                  |
| SUP        |     |           |           |   |   |                  |
| PLEMENTARY |     |           |           |   |   |                  |
| NOTES      |     |           |           |   |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 12a.       |     |           |           |   | 1 |                  |
| DISTR      |     |           |           |   | 2 |                  |
| IBUTION/AV |     |           |           |   | b |                  |
| AILABILITY |     |           |           |   | . |                  |
| STATEMENT  |     |           |           |   | D |                  |
|            |     |           |           |   | I |                  |
| This       |     |           |           |   | S |                  |
| document   |     |           |           |   | T |                  |
| is         |     |           |           |   | R |                  |
| available  |     |           |           |   | I |                  |
| to the     |     |           |           |   | B |                  |
| public     |     |           |           |   | U |                  |
| through    |     |           |           |   | T |                  |
| the        |     |           |           |   | I |                  |
| National   |     |           |           |   | O |                  |
| Technical  |     |           |           |   | N |                  |
| I          |     |           |           |   | C |                  |
| nformation |     |           |           |   | O |                  |
| Service,   |     |           |           |   | D |                  |
| Sp         |     |           |           |   | E |                  |
| ringfield, |     |           |           |   |   |                  |
| VA 22161   |     |           |           |   |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 13\.       |     |           |           |   |   |                  |
| ABSTRACT   |     |           |           |   |   |                  |
| (Maximum   |     |           |           |   |   |                  |
| 200 words) |     |           |           |   |   |                  |
|            |     |           |           |   |   |                  |
| This       |     |           |           |   |   |                  |
| report is  |     |           |           |   |   |                  |
| the latest |     |           |           |   |   |                  |
| in a       |     |           |           |   |   |                  |
| series of  |     |           |           |   |   |                  |
| State-     |     |           |           |   |   |                  |
| of-the-Art |     |           |           |   |   |                  |
| reports,   |     |           |           |   |   |                  |
| the last   |     |           |           |   |   |                  |
| of which   |     |           |           |   |   |                  |
| was        |     |           |           |   |   |                  |
| published  |     |           |           |   |   |                  |
| in         |     |           |           |   |   |                  |
| December   |     |           |           |   |   |                  |
| 2000. It   |     |           |           |   |   |                  |
| contains   |     |           |           |   |   |                  |
| the        |     |           |           |   |   |                  |
| results of |     |           |           |   |   |                  |
| a          |     |           |           |   |   |                  |
| high-level |     |           |           |   |   |                  |
| scan of    |     |           |           |   |   |                  |
| the extent |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| character  |     |           |           |   |   |                  |
| of the     |     |           |           |   |   |                  |
| adoption   |     |           |           |   |   |                  |
| and use of |     |           |           |   |   |                  |
| advanced   |     |           |           |   |   |                  |
| technology |     |           |           |   |   |                  |
| in the     |     |           |           |   |   |                  |
| provision  |     |           |           |   |   |                  |
| of public  |     |           |           |   |   |                  |
| tran       |     |           |           |   |   |                  |
| sportation |     |           |           |   |   |                  |
| services   |     |           |           |   |   |                  |
| in North   |     |           |           |   |   |                  |
| America.   |     |           |           |   |   |                  |
|            |     |           |           |   |   |                  |
| The        |     |           |           |   |   |                  |
| objective  |     |           |           |   |   |                  |
| of this    |     |           |           |   |   |                  |
| effort was |     |           |           |   |   |                  |
| to provide |     |           |           |   |   |                  |
| a useful   |     |           |           |   |   |                  |
| and timely |     |           |           |   |   |                  |
| reference  |     |           |           |   |   |                  |
| on the     |     |           |           |   |   |                  |
| subject of |     |           |           |   |   |                  |
| emerging   |     |           |           |   |   |                  |
| Transit    |     |           |           |   |   |                  |
| ITS        |     |           |           |   |   |                  |
| tec        |     |           |           |   |   |                  |
| hnological |     |           |           |   |   |                  |
| advances   |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| trends,    |     |           |           |   |   |                  |
| and make   |     |           |           |   |   |                  |
| the        |     |           |           |   |   |                  |
| i          |     |           |           |   |   |                  |
| nformation |     |           |           |   |   |                  |
| available  |     |           |           |   |   |                  |
| to public  |     |           |           |   |   |                  |
| tran       |     |           |           |   |   |                  |
| sportation |     |           |           |   |   |                  |
| prof       |     |           |           |   |   |                  |
| essionals. |     |           |           |   |   |                  |
| The report |     |           |           |   |   |                  |
| is         |     |           |           |   |   |                  |
| intended   |     |           |           |   |   |                  |
| to provide |     |           |           |   |   |                  |
| up to date |     |           |           |   |   |                  |
| i          |     |           |           |   |   |                  |
| nformation |     |           |           |   |   |                  |
| on the     |     |           |           |   |   |                  |
| current    |     |           |           |   |   |                  |
| deployment |     |           |           |   |   |                  |
| status of  |     |           |           |   |   |                  |
| transit    |     |           |           |   |   |                  |
| ITS        |     |           |           |   |   |                  |
| tec        |     |           |           |   |   |                  |
| hnologies, |     |           |           |   |   |                  |
| provide    |     |           |           |   |   |                  |
| lessons    |     |           |           |   |   |                  |
| learned    |     |           |           |   |   |                  |
| based on   |     |           |           |   |   |                  |
| deployment |     |           |           |   |   |                  |
| ex         |     |           |           |   |   |                  |
| periences, |     |           |           |   |   |                  |
| and        |     |           |           |   |   |                  |
| promote    |     |           |           |   |   |                  |
| und        |     |           |           |   |   |                  |
| erstanding |     |           |           |   |   |                  |
| of future  |     |           |           |   |   |                  |
| trends in  |     |           |           |   |   |                  |
| Advanced   |     |           |           |   |   |                  |
| Public     |     |           |           |   |   |                  |
| Tran       |     |           |           |   |   |                  |
| sportation |     |           |           |   |   |                  |
| Systems    |     |           |           |   |   |                  |
| (APTS).    |     |           |           |   |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
| 14\.       |     |           |           |   |   | 15\. NUMBER OF   |
| SUBJECT    |     |           |           |   |   | PAGES            |
| TERMS      |     |           |           |   |   |                  |
|            |     |           |           |   |   | 264              |
| Public     |     |           |           |   |   |                  |
| Transit,   |     |           |           |   |   |                  |
| I          |     |           |           |   |   |                  |
| ntelligent |     |           |           |   |   |                  |
| Tran       |     |           |           |   |   |                  |
| sportation |     |           |           |   |   |                  |
| Systems    |     |           |           |   |   |                  |
| (ITS),     |     |           |           |   |   |                  |
| Advanced   |     |           |           |   |   |                  |
| Public     |     |           |           |   |   |                  |
| Tran       |     |           |           |   |   |                  |
| sportation |     |           |           |   |   |                  |
| Systems    |     |           |           |   |   |                  |
| (APTS),    |     |           |           |   |   |                  |
| In         |     |           |           |   |   |                  |
| tegration, |     |           |           |   |   |                  |
| Fleet      |     |           |           |   |   |                  |
| M          |     |           |           |   |   |                  |
| anagement, |     |           |           |   |   |                  |
| Electronic |     |           |           |   |   |                  |
| Fare       |     |           |           |   |   |                  |
| Payment,   |     |           |           |   |   |                  |
| Traveler   |     |           |           |   |   |                  |
| In         |     |           |           |   |   |                  |
| formation, |     |           |           |   |   |                  |
| Transit    |     |           |           |   |   |                  |
| Safety and |     |           |           |   |   |                  |
| Security,  |     |           |           |   |   |                  |
| Tran       |     |           |           |   |   |                  |
| sportation |     |           |           |   |   |                  |
| Demand     |     |           |           |   |   |                  |
| M          |     |           |           |   |   |                  |
| anagement, |     |           |           |   |   |                  |
| I          |     |           |           |   |   |                  |
| ntelligent |     |           |           |   |   |                  |
| Vehicle    |     |           |           |   |   |                  |
| Systems    |     |           |           |   |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+
|            |     |           |           |   |   | 16\. PRICE CODE  |
+------------+-----+-----------+-----------+---+---+------------------+
| 17\.       | 1   |           | 19\.      |   |   | 20\. LIMITATION  |
| SECURITY   | 8\. |           | SECURITY  |   |   | OF ABSTRACT      |
| CLASS      | SE  |           | CLASSI    |   |   |                  |
| IFICATION\ | CUR |           | FICATION\ |   |   |                  |
| OF REPORT  | ITY |           | OF        |   |   |                  |
|            | CLA |           | ABSTRACT  |   |   |                  |
| Un         | SSI |           |           |   |   |                  |
| classified | FIC |           | Unc       |   |   |                  |
|            | ATI |           | lassified |   |   |                  |
|            | ON\ |           |           |   |   |                  |
|            | OF  |           |           |   |   |                  |
|            | T   |           |           |   |   |                  |
|            | HIS |           |           |   |   |                  |
|            | P   |           |           |   |   |                  |
|            | AGE |           |           |   |   |                  |
|            |     |           |           |   |   |                  |
|            | Unc |           |           |   |   |                  |
|            | las |           |           |   |   |                  |
|            | sif |           |           |   |   |                  |
|            | ied |           |           |   |   |                  |
+------------+-----+-----------+-----------+---+---+------------------+

*NOTICE:*

*This document is disseminated under the sponsorship of the United
States*

*Department of Transportation in the interest of information exchange.
The*

*United States Government assumes no liability for its contents or use
thereof.*

*The United States Government does not endorse manufacturers or
products.*

*Trade names appear in the document only because they are essential to
the*

*objective of this report.*

**ADVANCED PUBLIC**

**TRANSPORTATION SYSTEMS:**

**THE STATE OF THE ART**

**UPDATE 2006**

# Project Team

**FTA PERSONNEL**

Sean Ricketson, Contracting Officer's Technical Representative (COTR)

Aletha Goodine, Project Manager

Gwo-Wei Torng, Ph.D., Mitretek Systems

**RESEARCH TEAM MEMBERS**

Project Director Eva Lerner-Lam, Palisades Consulting Group, Inc.

Program Manager Mimi Hwang, Palisades Consulting Group, Inc.

Editor-in-Chief John Schiavone

Authors Mimi Hwang, Palisades Consulting Group, Inc.

James Kemp, Certified Project Management Group, LLC

Eva Lerner-Lam, Palisades Consulting Group, Inc.

Nancy Neuerburg, N-Squared Associates

Paula Okunieff, Systems and Solutions, Inc.

Administration Ellen Thompson, Palisades Consulting Group, Inc.

Lawrence Xiang, Palisades Consulting Group, Inc.

# FOREWORD

This report contains the final results of a high-level scan of the
transit industry, including interviews and analysis, concerning the
status of state-of-the-art Intelligent Transportation System (ITS)
applications to public transit service in North America. The objective
of this effort was to increase the transit community's knowledge of new
opportunities, challenges, and lessons learned by agencies and suppliers
in applying advanced technologies to improve the efficiency,
effectiveness, reliability, safety, and security of public transit
services.

Key observations from the research include:

-   The complexities associated with state-of-the-art ITS technologies
    exceed the transit community's current ability to deploy them and
    stay abreast of ongoing developments.

-   Key obstacles include:

    -   The stand-alone nature of most individual technology deployments
        limits the benefits that could be provided by business-oriented,
        enterprise-wide technology strategies;

    -   Most technology-based applications require continuous
        cooperation and coordination between and among many different
        departments, agencies, and jurisdictions that are often
        difficult to achieve;

    -   Limited resources and gaps in education and training in the
        integration, use, and maintenance of technologies and the
        standards necessary for interoperability and data sharing make
        it difficult for transit professionals to keep up with
        technological developments and opportunities;

    -   Fast-paced changes in technologies put deployment efforts at
        risk.

-   Looking ahead:

    -   The greatest improvements to ITS will come from efforts to
        integrate existing technologies into cohesive state-of-the-art
        *systems,* where collectively they provide far more benefits
        than any one technology functioning independently;

    -   Federal efforts to provide opportunities for peer group
        knowledge-sharing, education, and training would help foster a
        better understanding of opportunities and challenges of
        state-of-the-art technologies.

# Table of Contents

[**Report Documentation Page 2**](#report-documentation-page)

[Project Team 4](#project-team)

[Foreword 5](#foreword)

[Table of Contents 6](#table-of-contents)

[List of Figures 15](#list-of-figures)

[List of Tables 16](#list-of-tables)

[Acronyms and Abbreviations 17](#acronyms-and-abbreviations)

[Executive Summary 19](#executive-summary)

[Chapter 1 Introduction 33](#chapter-1-introduction)

[1.1 Background 33](#background)

[1.2 New Report Approach 33](#new-report-approach)

[1.3 Defining "State of the Art" 33](#defining-state-of-the-art)

[1.4 New Typology Organization 34](#new-typology-organization)

[1.5 Intended Audience 36](#intended-audience)

[1.6 Report Objective and Methodology
36](#report-objective-and-methodology)

[1.6.1 Report Objective 36](#report-objective)

[1.6.2 Report Methodology 36](#report-methodology)

[1.7 Report Organization 37](#report-organization)

[Chapter 2 Integration 38](#chapter-2-integration)

[2.1 Introduction and Technology Overview
38](#introduction-and-technology-overview)

[2.1.1 Need for Integration 38](#need-for-integration)

[2.1.2 Integration Subcategories 40](#integration-subcategories)

[2.1.3 Institutional Support of Integration and Sharing
42](#institutional-support-of-integration-and-sharing)

[2.2 Transit ITS Architecture 43](#transit-its-architecture)

[2.2.1 Technology Description 44](#technology-description)

[2.2.1.1 FTA Policy 44](#fta-policy)

[2.2.1.2 Regional ITS Architecture 45](#regional-its-architecture)

[2.2.1.3 Systems Engineering Requirements and Procurement Implications
45](#systems-engineering-requirements-and-procurement-implications)

[2.2.1.4 Transit Internal Architecture
46](#transit-internal-architecture)

[2.2.2 State of the Art 48](#state-of-the-art)

[2.2.3 Emerging Trends 49](#emerging-trends)

[2.2.4 Challenges and Lessons Learned
49](#challenges-and-lessons-learned)

[2.3 Enterprise Data 50](#enterprise-data)

[2.3.1 Technology Description 51](#technology-description-1)

[2.3.1.1 Application-centric and Progression to Data-centric
52](#application-centric-and-progression-to-data-centric)

[2.3.2 State of the Art 55](#state-of-the-art-1)

[2.3.2.1 King County Metro (KCM) Transit Enterprise Database (TED)
55](#king-county-metro-kcm-transit-enterprise-database-ted)

[2.3.2.2 TriMet Enterprise Database 56](#trimet-enterprise-database)

[2.3.2.3 WMATA Interactive Electronic Technical Manuals (IETM)
57](#wmata-interactive-electronic-technical-manuals-ietm)

[2.3.2.4 NJ Transit Data Warehouse 59](#nj-transit-data-warehouse)

[2.3.3 Emerging Trends 59](#emerging-trends-1)

[2.3.3.1 Regional Transit Stop Inventory
59](#regional-transit-stop-inventory)

[2.3.4 Challenges and Lessons Learned
60](#challenges-and-lessons-learned-1)

[2.4 Geographic Information Systems (GIS)
61](#geographic-information-systems-gis)

[2.4.1 Technology Description 62](#technology-description-2)

[2.4.2 State of the Art 62](#state-of-the-art-2)

[2.4.3 Emerging Examples 70](#emerging-examples)

[2.4.3.1 Emerging Spatial Information Standards
70](#emerging-spatial-information-standards)

[2.4.4 Challenges and Lessons Learned
72](#challenges-and-lessons-learned-2)

[2.4.4.1 Barriers to Sharing Spatial Data
72](#barriers-to-sharing-spatial-data)

[2.4.4.2 Lessons Learned 72](#lessons-learned)

[2.5 Communications 74](#communications)

[2.5.1 Technology Description 75](#technology-description-3)

[2.5.1.1 Wide Area Communications 77](#wide-area-communications)

[2.5.1.2 Short-Range Communications: WiFi, WiMAX, and DSRC/WAVE
78](#short-range-communications-wifi-wimax-and-dsrcwave)

[2.5.1.2.1 WiMAX 79](#wimax)

[2.5.1.2.2 WiMAX versus Wi-Fi 80](#wimax-versus-wi-fi)

[2.5.1.2.3 DSRC and WAVE 81](#dsrc-and-wave)

[2.5.1.3 Corridor and Metropolitan Area Communications: Mesh Networks
83](#corridor-and-metropolitan-area-communications-mesh-networks)

[2.5.2 State of the Art 84](#state-of-the-art-3)

[2.5.3 Emerging Trends 85](#emerging-trends-2)

[2.5.3.1 Refarming 85](#refarming)

[2.5.3.2 Cellular Digital Packet Data (CDPD)
85](#cellular-digital-packet-data-cdpd)

[2.5.3.3 APCO P25 85](#apco-p25)

[2.5.3.4 Others 86](#others)

[2.5.3.5 Wireless Internet 86](#wireless-internet)

[2.5.3.6 IEEE 802.11-based Transit Signal Priority; Wireless Networks\
in Lieu of Inground Communications Infrastructure
88](#ieee-802.11-based-transit-signal-priority-wireless-networks-in-lieu-of-inground-communications-infrastructure)

[2.5.3.7 Data Transmission over Conventional Analog Radio
88](#data-transmission-over-conventional-analog-radio)

[2.5.3.8 Public Access Wireless Infrastructures
89](#public-access-wireless-infrastructures)

[2.5.4 Challenges and Lessons Learned
89](#challenges-and-lessons-learned-3)

[2.5.4.1 Interoperable Communications for Emergency Management
89](#interoperable-communications-for-emergency-management)

[2.5.4.2 Sub-Optimization of Design Constraints
90](#sub-optimization-of-design-constraints)

[2.5.4.3 Public Access Wireless Infrastructures
90](#public-access-wireless-infrastructures-1)

[2.5.4.4 Shifting Technology Needs 91](#shifting-technology-needs)

[2.5.4.5 User Support 91](#user-support)

[2.5.4.6 Evolving Technologies 91](#evolving-technologies)

[2.5.4.6.1 "Just in Time" Technology Procurement
91](#just-in-time-technology-procurement)

[2.5.4.6.2 Communications Infrastructure Supportability and\
Administration
92](#communications-infrastructure-supportability-and-administration)

[2.6 Transit ITS Standards 92](#transit-its-standards)

[2.6.1 Standard Descriptions 92](#standard-descriptions)

[2.6.1.1 Integrated Fare Management Standards
95](#integrated-fare-management-standards)

[2.6.1.1.1 U.S. Fare Card Standard Efforts
95](#u.s.-fare-card-standard-efforts)

[2.6.1.1.1a Media Standards 95](#a-media-standards)

[2.6.1.1.1b APTA Universal Transit Farecard Standards
95](#b-apta-universal-transit-farecard-standards)

[2.6.1.1.2 Transit Communications Interface Profiles: WG 7 Fare
Collection
97](#transit-communications-interface-profiles-wg-7-fare-collection)

[2.6.1.1.3 International Efforts 98](#international-efforts)

[2.6.1.1.4 INCITS Transit Fare Cards --- Interoperability Framework for
Contactless Fare Payment Technologies and Systems
99](#incits-transit-fare-cards-interoperability-framework-for-contactless-fare-payment-technologies-and-systems)

[2.6.1.2 Transit Communications Interface Profile (TCIP)\
Versions 2.x and 3.0
99](#transit-communications-interface-profile-tcip-versions-2.x-and-3.0)

[2.6.1.3 Bus Vehicle Area Network (SAE 1708 family of standards)
100](#bus-vehicle-area-network-sae-1708-family-of-standards)

[2.6.1.4 Related Standards Efforts 102](#related-standards-efforts)

[2.6.1.4.1 Signal Control and Prioritization (NTCIP 1211)
102](#signal-control-and-prioritization-ntcip-1211)

[2.6.1.4.2 NTCIP 2306 Center to Center SOAP Interchange
103](#ntcip-2306-center-to-center-soap-interchange)

[2.6.1.4.3 SAE Advanced Traveler Information Systems /\
Location Referencing Message Specification
103](#sae-advanced-traveler-information-systems-location-referencing-message-specification)

[2.6.1.4.4 Metadata and Archiving Standards / Standard Guide for\
Archiving and Retrieving ITS-Generated Data (E2259-03a)
104](#metadata-and-archiving-standards-standard-guide-for-archiving-and-retrieving-its-generated-data-e2259-03a)

[2.6.1.5 ISO TC 204 Working Group 8 104](#iso-tc-204-working-group-8)

[2.6.1.5.1 Transmodel 104](#transmodel)

[2.6.1.5.2 Standard Numbering System for Public Transport Stops\
(SNSPTS)
105](#standard-numbering-system-for-public-transport-stops-snspts)

[2.6.1.5.3 PRESTO 105](#presto)

[2.6.1.6 GeoSpatial One Stop (GOS): Geographic Information Frame-work,
Data Content Standard, Transportation: Transit (Part 7d)
105](#geospatial-one-stop-gos-geographic-information-frame-work-data-content-standard-transportation-transit-part-7d)

[2.6.2 State of the Art 106](#state-of-the-art-4)

[2.6.3 Challenges and Lessons Learned
107](#challenges-and-lessons-learned-4)

[2.7 References 108](#references)

[Chapter 3 Fleet Management 111](#chapter-3-fleet-management)

[3.1 Introduction 111](#introduction)

[3.2 Service Planning Support Systems
114](#service-planning-support-systems)

[3.2.1 Technology Description 114](#technology-description-4)

[3.2.2 State of the Art 115](#state-of-the-art-5)

[3.2.3 Emerging Trends 116](#emerging-trends-3)

[3.2.4 Challenges and Lessons Learned
116](#challenges-and-lessons-learned-5)

[3.3 Transit Priority Treatment 117](#transit-priority-treatment)

[3.3.1 Technology Description 117](#technology-description-5)

[3.3.2 State of the Art 118](#state-of-the-art-6)

[3.3.3 Emerging Trends 119](#emerging-trends-4)

[3.3.4 Challenges and Lessons Learned
119](#challenges-and-lessons-learned-6)

[3.4 Maintenance Management Systems
121](#maintenance-management-systems)

[3.4.1 Technology Description 121](#technology-description-6)

[3.4.2 State of the Art 122](#state-of-the-art-7)

[3.4.3 Emerging Trends 123](#emerging-trends-5)

[3.4.4 Challenges and Lessons Learned
123](#challenges-and-lessons-learned-7)

[3.5 Transportation Operations Systems
123](#transportation-operations-systems)

[3.5.1 Technology Description 123](#technology-description-7)

[3.5.1.1 Rail Operations Control Systems
124](#rail-operations-control-systems)

[3.5.1.2 Bus Operations Systems 125](#bus-operations-systems)

[3.5.1.3 Paratransit Operations Systems
125](#paratransit-operations-systems)

[3.5.1.4 Other Operations Systems 126](#other-operations-systems)

[3.5.2 State of the Art 126](#state-of-the-art-8)

[3.5.3 Emerging Trends 129](#emerging-trends-6)

[3.5.3.1 Modularization 129](#modularization)

[3.5.3.2 Remote Vehicle Disable 130](#remote-vehicle-disable)

[3.5.4 Challenges and Lessons Learned: General Transportation\
Operations Systems
130](#challenges-and-lessons-learned-general-transportation-operations-systems)

[3.5.4.1 Specifications 130](#specifications)

[3.5.4.2 Testing 132](#testing)

[3.5.4.3 Vehicle Installations 133](#vehicle-installations)

[3.5.4.4 Test Bench 133](#test-bench)

[3.5.4.5 Custom Development 134](#custom-development)

[3.5.4.6 Achievable Scope 134](#achievable-scope)

[3.5.4.7 Test Environment 135](#test-environment)

[3.5.4.8 Ownership of Data 135](#ownership-of-data)

[3.5.4.9 Operational Flexibility 135](#operational-flexibility)

[3.5.4.10 Project Planning and Project Management
135](#project-planning-and-project-management)

[3.5.4.10.1 Comprehensive Technology Plan
135](#comprehensive-technology-plan)

[3.5.4.10.2 Risk Management 135](#risk-management)

[3.5.4.10.3 Dedicated Project Manager 136](#dedicated-project-manager)

[3.5.4.10.4 ITS Architecture Policy Compliance
136](#its-architecture-policy-compliance)

[3.5.4.11 Procurement 136](#procurement)

[3.5.4.11.1 Value Engineering 136](#value-engineering)

[3.5.4.11.2 Canned Specifications 136](#canned-specifications)

[3.5.4.11.3 Quality of Proposals 137](#quality-of-proposals)

[3.5.4.11.4 Procuring for Best Achievable Value
137](#procuring-for-best-achievable-value)

[3.5.4.12 Standards 138](#standards)

[3.5.4.12.1 Use of Standards 138](#use-of-standards)

[3.5.4.12.2 Transit Communications Interface Profiles (TCIP)
139](#transit-communications-interface-profiles-tcip)

[3.5.4.12.3 J1708 Compliance 139](#j1708-compliance)

[3.6 Lessons Learned: Rail Operations Control Systems
140](#lessons-learned-rail-operations-control-systems)

[3.6.1 Dark Territory 140](#dark-territory)

[3.6.2 Train ID 140](#train-id)

[3.7 Lessons Learned: Bus Operations Systems
141](#lessons-learned-bus-operations-systems)

[3.7.1 Designing for Modular System Upgrade and Expansion
141](#designing-for-modular-system-upgrade-and-expansion)

[3.7.2 Communications 141](#communications-1)

[3.8 Lessons Learned: Paratransit Operations Systems
142](#lessons-learned-paratransit-operations-systems)

[3.8.1 Multiple Providers 142](#multiple-providers)

[3.8.2 Verification of Service Delivery
142](#verification-of-service-delivery)

[3.9 Lessons Learned: Other Operations Systems
142](#lessons-learned-other-operations-systems)

[3.9.1 Elevator and Escalator Status
142](#elevator-and-escalator-status)

[3.9.2 Crowd Control 142](#crowd-control)

[3.10 References 142](#references-1)

[Chapter 4 Electronic Fare Payment
144](#chapter-4-electronic-fare-payment)

[4.1 Introduction and Technology Overview
144](#introduction-and-technology-overview-1)

[4.2 Fare Systems 145](#fare-systems)

[4.2.1 Technology Description 145](#technology-description-8)

[4.2.1.1 Electronic Fare Collection Systems to Solve Complexity and\
Provide Integration
148](#electronic-fare-collection-systems-to-solve-complexity-and-provide-integration)

[4.2.1.2 Smart Card-Based Fare Systems
148](#smart-card-based-fare-systems)

[4.2.1.3 Facilitation of New Marketing and Incentive Options
149](#facilitation-of-new-marketing-and-incentive-options)

[4.2.1.4 Systems with Non-Transportation Agency Partnerships
149](#systems-with-non-transportation-agency-partnerships)

[4.2.1.5 Paratransit Applications 150](#paratransit-applications)

[4.2.2 State of the Art 150](#state-of-the-art-9)

[4.2.2.1 LACMTA 151](#lacmta)

[4.2.2.2 ORANGES 152](#oranges)

[4.2.2.3 San Francisco Bay Area 152](#san-francisco-bay-area)

[4.2.2.4 Maryland's Mobility Cards 152](#marylands-mobility-cards)

[4.2.2.5 eCommerce and Online Stores for Fare Products
153](#ecommerce-and-online-stores-for-fare-products)

[4.2.2.6 Emerging Trends 153](#emerging-trends-7)

[4.2.2.6.1 San Diego Metropolitan Transit System (MTS)
153](#san-diego-metropolitan-transit-system-mts)

[4.2.2.6.2 Utah Transit Authority (UTA)
154](#utah-transit-authority-uta)

[4.2.2.6.3 Northern Shenandoah Valley (NSV) Public Mobility Program
154](#northern-shenandoah-valley-nsv-public-mobility-program)

[4.2.2.6.4 Capital Area Rural Transportation System (CARTS)
156](#capital-area-rural-transportation-system-carts)

[4.2.2.6.5 Other 157](#other)

[4.3 Fare Payment Products (Media) 157](#fare-payment-products-media)

[4.3.1 Technology Description 157](#technology-description-9)

[4.3.2 Changing Environment 158](#changing-environment)

[4.3.3 State of the Art 158](#state-of-the-art-10)

[4.3.4 Emerging Trends 159](#emerging-trends-8)

[4.4 Clearinghouse/Regional Service Center (CH/RSC)
160](#clearinghouseregional-service-center-chrsc)

[4.4.1 Technology Description 162](#technology-description-10)

[4.4.2 State of the Art 162](#state-of-the-art-11)

[4.5 Challenges and Lessons Learned
164](#challenges-and-lessons-learned-8)

[4.5.1 Integration and Interoperability
164](#integration-and-interoperability)

[4.5.2 Regional Systems 165](#regional-systems)

[4.5.3 Standards 165](#standards-1)

[4.5.4 Equipment 166](#equipment)

[4.5.5 Other Challenges and Lessons Learned
167](#other-challenges-and-lessons-learned)

[4.6 References 169](#references-2)

[Chapter 5 Traveler Information 170](#chapter-5-traveler-information)

[5.1 Introduction and Technology Overview
170](#introduction-and-technology-overview-2)

[5.2 Transit Information Systems 171](#transit-information-systems)

[5.2.1 Technology Description 171](#technology-description-11)

[5.2.2 State of the Art 173](#state-of-the-art-12)

[5.3 Transit Trip Information Infrastructure
178](#transit-trip-information-infrastructure)

[5.3.1 Technology Description 178](#technology-description-12)

[5.3.1.1 Technological Features 179](#technological-features)

[5.3.1.2 Data Integration 179](#data-integration)

[5.3.1.3 Regional Deployment Considerations
180](#regional-deployment-considerations)

[5.3.1.3.1 Coordination and Administration Processes
180](#coordination-and-administration-processes)

[5.3.1.3.2 Real-Time Data Quality Management
180](#real-time-data-quality-management)

[5.3.2 State of the Art 181](#state-of-the-art-13)

[5.4 Emerging Trends 183](#emerging-trends-9)

[5.4.1 Examples of Emerging Trends 184](#examples-of-emerging-trends)

[5.5 Challenges and Lessons Learned
187](#challenges-and-lessons-learned-9)

[5.5.1 Key Lessons Learned 187](#key-lessons-learned)

[5.5.2 Regional Trip Planning Lessons Learned
188](#regional-trip-planning-lessons-learned)

[5.5.3 Maps and Networks Lessons Learned
188](#maps-and-networks-lessons-learned)

[5.5.4 Voice Recognition Lessons learned
189](#voice-recognition-lessons-learned)

[5.5.5 Real-Time Lag Lessons Learned
189](#real-time-lag-lessons-learned)

[5.5.6 Communications Lessons Learned
190](#communications-lessons-learned)

[5.5.7 Bus Stop Data Lessons Learned
190](#bus-stop-data-lessons-learned)

[5.5.8 Floodgate Messages Lessons Learned
190](#floodgate-messages-lessons-learned)

[5.5.9 Miscellaneous Lessons Learned
190](#miscellaneous-lessons-learned)

[5.6 References 191](#references-3)

[Chapter 6 Transit Safety and Security
193](#chapter-6-transit-safety-and-security)

[6.1 Introduction and Technology Overview
193](#introduction-and-technology-overview-3)

[6.1.1 Transit Safety and Security 193](#transit-safety-and-security)

[6.1.2 Increased Sense of Urgency 194](#increased-sense-of-urgency)

[6.2 Onboard Safety and Security 195](#onboard-safety-and-security)

[6.2.1 Technology Description 195](#technology-description-13)

[6.2.1.1 Voice Communications 195](#voice-communications)

[6.2.1.2 Video Assessment Systems 196](#video-assessment-systems)

[6.2.2 State of the Art 196](#state-of-the-art-14)

[6.2.2.1 Interoperable Radio Communications
196](#interoperable-radio-communications)

[6.2.2.2 Video Assessment Systems 197](#video-assessment-systems-1)

[6.3 Station/Facility Safety and Security
197](#stationfacility-safety-and-security)

[6.3.1 Technology Description 197](#technology-description-14)

[6.3.2 State of the Art 198](#state-of-the-art-15)

[6.4 Incident Response 200](#incident-response)

[6.4.1 Technology Description 200](#technology-description-15)

[6.4.1.1 Detection/Assessment 200](#detectionassessment)

[6.4.1.2 Response/Evacuation 200](#responseevacuation)

[6.4.1.3 Communications 201](#communications-2)

[6.4.2 State of the Art 201](#state-of-the-art-16)

[6.4.2.1 Detection 201](#detection)

[6.4.2.2 Response/Evacuation 202](#responseevacuation-1)

[6.4.2.3 Communications 202](#communications-3)

[6.5 Incident and Disaster Planning Support Systems
202](#incident-and-disaster-planning-support-systems)

[6.5.1 Technology Description 202](#technology-description-16)

[6.5.2 State of the Art 203](#state-of-the-art-17)

[6.6 Challenges and Lessons Learned
204](#challenges-and-lessons-learned-10)

[6.7 Agency/Vendor Examples 204](#agencyvendor-examples)

[6.7.1 Video Assessment Systems---New Jersey Transit Corporation (NJT)
204](#video-assessment-systemsnew-jersey-transit-corporation-njt)

[6.7.2 Chemical Detection Systems --- WMATA
205](#chemical-detection-systems-wmata)

[6.7.3 Transit Mobile Broadband Communications---Cedar Rapids, IA
206](#transit-mobile-broadband-communicationscedar-rapids-ia)

[6.8 References 207](#references-4)

[Chapter 7 Transportation Demand Management
210](#chapter-7-transportation-demand-management)

[7.1 Introduction and Technology Overview
210](#introduction-and-technology-overview-4)

[7.2 Dynamic Ridesharing 214](#dynamic-ridesharing)

[7.2.1 Technology Description 214](#technology-description-17)

[7.2.2 State of the Art 216](#state-of-the-art-18)

[7.2.3 Emerging Trends 217](#emerging-trends-10)

[7.3 Automated Service Coordination
218](#automated-service-coordination)

[7.3.1 Technology Description 218](#technology-description-18)

[7.3.2 State of the Art 220](#state-of-the-art-19)

[7.3.3 Emerging Trends 221](#emerging-trends-11)

[7.4 Multimodal Transportation Management Centers
221](#multimodal-transportation-management-centers)

[7.4.1 Technology Description 221](#technology-description-19)

[7.4.2 State of the Art 224](#state-of-the-art-20)

[7.4.3 Emerging Trends 227](#emerging-trends-12)

[7.5 Challenges and Lessons Learned
227](#challenges-and-lessons-learned-11)

[7.5.1 Dynamic Rideshare Lessons Learned
227](#dynamic-rideshare-lessons-learned)

[7.5.2 Automated Service Coordination Lessons Learned
228](#automated-service-coordination-lessons-learned)

[7.5.3 Multimodal Transportation Management Center Lessons Learned
228](#multimodal-transportation-management-center-lessons-learned)

[7.6 References 230](#references-5)

[Chapter 8 Intelligent Vehicle Systems
231](#chapter-8-intelligent-vehicle-systems)

[8.1 Introduction and Technology Overview
231](#introduction-and-technology-overview-5)

[8.2 Intelligent Onboard Bus Integration
233](#intelligent-onboard-bus-integration)

[8.2.1 Technology Description 233](#technology-description-20)

[8.2.2 State of the Art 236](#state-of-the-art-21)

[8.2.3 Emerging Trends 238](#emerging-trends-13)

[8.3 Advanced Vehicle Safety Systems
239](#advanced-vehicle-safety-systems)

[8.3.1 Technology Description 239](#technology-description-21)

[8.3.2 State of the Art 242](#state-of-the-art-22)

[8.3.3 Emerging Trends 242](#emerging-trends-14)

[8.4 Vehicle Guidance/Automation 242](#vehicle-guidanceautomation)

[8.4.1 Technology Description 242](#technology-description-22)

[8.4.2 State of the Art 244](#state-of-the-art-23)

[8.4.3 Emerging Trends 245](#emerging-trends-15)

[8.5 Intelligent Rail Vehicle Integration
245](#intelligent-rail-vehicle-integration)

[8.5.1 Technology Description 245](#technology-description-23)

[8.5.2 State of the Art 247](#state-of-the-art-24)

[8.5.3 Emerging Trends 248](#emerging-trends-16)

[8.6 Challenges and Lessons Learned
248](#challenges-and-lessons-learned-12)

[8.6.1 Use of Standards 248](#use-of-standards-1)

[8.6.2 Avoiding Sub-optimized Implementations
249](#avoiding-sub-optimized-implementations)

[8.6.3 Vehicle Networks 249](#vehicle-networks)

[8.6.4 System Administration 250](#system-administration)

[8.6.5 Intelligent System Integration
250](#intelligent-system-integration)

[8.6.6 Advanced Vehicle Safety Systems
251](#advanced-vehicle-safety-systems-1)

[8.7 References 251](#references-6)

[Appendix A Press Release Dated May 23, 2005
253](#appendix-a-press-release-dated-may-23-2005)

[Appendix B State of the Art Update Survey
255](#appendix-b-state-of-the-art-update-survey)

[Appendix C Information Technology (IT) Local Area/Wide Area\
Networking Strategies
259](#appendix-c-information-technology-it-local-areawide-area-networking-strategies)

[Appendix D Fleet Management Example of a Performance-Based\
Specification Template
260](#appendix-d-fleet-management-example-of-a-performance-based-specification-template)

[Appendix E List of Contacts 263](#appendix-e-list-of-contacts)

# List of Figures

[Figure 1 Updated Transit ITS Typology 20](#__RefHeading___Toc129324143)

[Figure 2 Recommended Transit ITS Typology
35](#__RefHeading___Toc129324144)

[Figure 3 Locations with Shared ITS-Related Resources
40](#__RefHeading___Toc129324145)

[Figure 4 "Spaghetti Model of Interfaces"
52](#__RefHeading___Toc129324146)

[Figure 5 Corporate Data Evolution from Application-Centric to
Data-Centric Approach 54](#__RefHeading___Toc129324147)

[Figure 6 Functional Architecture of WMATA Interactive Electronic
Technical Manuals (IETM) 58](#__RefHeading___Toc129324148)

[Figure 7 Example from TriMet's Interactive Transit Map
65](#__RefHeading___Toc129324149)

[Figure 8 Ridership Analysis Example from TriMet's Bus Dispatch\
System Mapper 66](#__RefHeading___Toc129324150)

[Figure 9 Interactive Metrorail Map from WMATA
68](#__RefHeading___Toc129324151)

[Figure 10 Example from KCM's Stop Information System
69](#__RefHeading___Toc129324152)

[Figure 11 WMATA Conceptual Communications Network
76](#__RefHeading___Toc129324153)

[Figure 12 UTFS Work Package (WP) Scope
97](#__RefHeading___Toc129324154)

[Figure 13 Fleet Management State-of-the-Art
112](#__RefHeading___Toc129324155)

[Figure 14 Fleet Management In-Vehicle Technologies
113](#__RefHeading___Toc129324156)

[Figure 15 Transportation Operations System Block Diagram
124](#__RefHeading___Toc129324157)

[Figure 16 Fare Management System Architecture
146](#__RefHeading___Toc129324158)

[Figure 17 Northern Shenandoah Valley Smart Card Interface
156](#__RefHeading___Toc129324159)

[Figure 18 NJ TRANSIT Station-to-Station Application
176](#__RefHeading___Toc129324160)

[Figure 19 Wireless Options for Traveler Information at RTD-Denver
177](#__RefHeading___Toc129324161)

[Figure 20 Example of TriMet's Interactive Mapping Options
177](#__RefHeading___Toc129324162)

[Figure 21 NJ TRANSIT Bus Management Information System Onboard
Architecture 236](#__RefHeading___Toc129324163)

# List of Tables 

[Table 1 APTS State-of-the-Art Update 2006 Highlights
21](#__RefHeading___Toc129324321)

[Table 2 Integration Subcategories 41](#__RefHeading___Toc129324322)

[Table 3 Summary of Wi-Fi and WiMAX Technologies
80](#__RefHeading___Toc129324323)

[Table 4 DSRC 5.9 GHz Prototype Attributes
82](#__RefHeading___Toc129324324)

[Table 5 Standard Types and Descriptions
93](#__RefHeading___Toc129324325)

[Table 6 Family of SAE Vehicle Network Standards
101](#__RefHeading___Toc129324326)

[Table 7 Summaries of Standard Efforts
106](#__RefHeading___Toc129324327)

[Table 8 Types of Traveler Information Systems
172](#__RefHeading___Toc129324328)

# Acronyms and Abbreviations

> AAR Association of American Railroads
>
> ABS Anti-Lock Brake System
>
> ADA Americans with Disabilities Act
>
> APTA American Public Transportation Association
>
> APTS Advanced Public Transportation Systems
>
> AVL Automatic Vehicle Location
>
> CAD Computer Aided Dispatch
>
> CBTC Communications-Based Train Control
>
> COTS Commercial Off the Shelf
>
> DOT Department of Transportation
>
> DSRC Dedicated Short-Range Communication
>
> EIA Electronic Industries Alliance
>
> FAR Federal Acquisition Regulations
>
> FCC Federal Communications Commission
>
> FHWA Federal Highway Administration
>
> FTA Federal Transit Administration
>
> GIS Geographic Information System
>
> GPS Global Positioning System
>
> HAR Highway Advisory Radio
>
> HOV High Occupancy Vehicle
>
> HUD "Heads Up" Display
>
> ID Identification
>
> IEEE Institute of Electrical and Electronics Engineers
>
> IP Internet Protocol
>
> IT Information Technology
>
> ITE Institute of Transportation Engineers
>
> ITS Intelligent Transportation System
>
> IVR Interactive Voice Response
>
> IVS Intelligent Vehicle System
>
> JPO Joint Program Office
>
> LACMTA Los Angeles County Metropolitan Transportation Authority
>
> LCC Life Cycle Cost
>
> MDT Mobile Data Terminal
>
> MPO Metropolitan Planning Organization
>
> NJT New Jersey Transit
>
> NHTSA National Highway Traffic Safety Administration
>
> NTCIP National Transportation Communications for ITS Protocols
>
> NTI National Transit Institute
>
> NYCTA New York City Transit Authority
>
> PC Personal Computer
>
> PDA Personal Digital Assistant
>
> PRT Personal Rapid Transit
>
> RADAR Short range Radio Direction and Ranging
>
> RF Radio Frequency
>
> RFID Radio Frequency Identification
>
> RFP Request for Proposals
>
> SAE Society of Automotive Engineers
>
> SCADA Supervisory Control and Data Acquisition
>
> SOA State-of-the-Art
>
> TCIP Transit Communications Interface Profiles
>
> TCRP Transit Cooperative Research Program
>
> TDM Transportation Demand Management
>
> TEA 21 Transportation Equity Act for the 21st Century
>
> TMA Transportation Management Associations
>
> TRB Transportation Research Board
>
> TSC Transit Standards Consortium
>
> TSP Transit Signal Priority
>
> VAN Vehicle Area Network
>
> VLU Vehicle Logic Unit
>
> VMS Variable Message Signs
>
> VoIP Voice over Internet Protocol
>
> VPN Virtual Private Network
>
> WI-FI Wireless Fidelity
>
> Wi-MAX Worldwide Interoperability for Microwave Access
>
> XML Extensible Markup Language

# Executive Summary

This *Advanced Public Transportation Systems: State-of-the-Art Update
2006* is the seventh in a series of reports first established in 1991 by
the Federal Transit Administration (FTA) to provide transit
professionals with a useful and timely reference on the subject of
emerging transit Intelligent Transportation System (ITS) advances and
trends.

The concept of ITS, which began in the 1960s in response to increasing
traffic congestion, was officially established by the United States
Congress in 1991. ITS applies a broad range of technologies to integrate
surface transportation infrastructures and vehicles to improve
efficiency, safety, and customer service. Advanced Public Transportation
Systems (APTS) is the transit component of ITS.

A significant change from past reports is reorganizing the APTS
typologies into categories that more accurately reflect ITS advances. A
new category titled "Integration," which encompasses the ITS National
Architecture and cross-cutting technologies, is placed as the
centerpiece of the typology because of its essential role in linking and
leveraging ITS applications. Other changes include the addition of
information that highlights the importance of agency-wide data and data
infrastructure. Some typology subcategories are new or retiled to
introduce new terminology, and to highlight many of the underlying
support systems and business processes.

Figure 1 shows the updated Transit ITS typology classification. Each
major typology heading corresponds to a report chapter. For the reader's
convenience, Table 1 highlights selected findings from each chapter. The
table includes a general introduction to the topic followed by a brief
technology overview, examples of state-of-the-art applications, and a
sample of challenges and lessons learned from deploying the various
technologies.

[]{#__RefHeading___Toc129324143 .anchor}Figure 1 Updated Transit ITS
Typology

![](media/image8.wmf)

[]{#__RefHeading___Toc129324321 .anchor}Table 1 APTS State-of-the-Art
Update 2006 Highlights

+---------------+------------------------------------------------------+
| **CHAPTER 2:  |                                                      |
| INTEGRATION** |                                                      |
+---------------+------------------------------------------------------+
| >             | ● Facilitates a cohesive "system" of interconnected  |
|  Introduction | ITS applications that collectively produce services  |
|               | and advantages far greater than any one application  |
|               | could achieve independently                          |
+---------------+------------------------------------------------------+
| **Transit ITS |                                                      |
| A             |                                                      |
| rchitecture** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● The National ITS Architecture serves as the        |
| > Overview    | framework for developing integrated transportation   |
|               | systems                                              |
|               |                                                      |
|               | ● Supports regional internal Information Technology  |
|               | (IT)/ITS and project architectures                   |
|               |                                                      |
|               | ● Enterprise Architecture Planning (EAP) reinforces  |
|               | success                                              |
+---------------+------------------------------------------------------+
| > State of    | ● Regional internal agency and project architecture  |
| > the Art     | applications that leverage transit resources,        |
|               | minimize duplication, and offer seamless transit     |
|               | services for customers                               |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Important to link agency ITS and IT architectures  |
| > and Lessons |                                                      |
| > Learned     | ● FTA's policy regarding systems engineering is      |
|               | extremely important when developing ITS projects     |
|               |                                                      |
|               | ● Develop strategies for sharing data resources and  |
|               | data maintenance activities with external            |
|               | organizations                                        |
+---------------+------------------------------------------------------+
| **Enterprise  |                                                      |
| Data**        |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Core data used by multiple organizational units    |
| > Overview    | and applications describing services, facilities,    |
|               | assets, and other key information                    |
|               |                                                      |
|               | ● Data management and reporting tools, logical data  |
|               | model, data policies and procedures                  |
+---------------+------------------------------------------------------+
| > State of    | ● The use of agency-wide or regional data            |
| > the Art     | dictionaries, architectures, data models and         |
|               | standards, and integration strategies                |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Manage core service and operational data from an   |
| > and Lessons | integrated, enterprise-wide perspective              |
| > Learned     |                                                      |
|               | ● Effective information management requires a plan   |
|               | supported by senior management                       |
|               |                                                      |
|               | ● Develop a clear set of requirements and reports    |
|               | that meet business needs and challenges before       |
|               | developing applications                              |
+---------------+------------------------------------------------------+
| **Geographic  |                                                      |
| Information   |                                                      |
| Systems       |                                                      |
| (GIS)**       |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Provides tools for creating, managing, analyzing,  |
| > Overview    | displaying spatial data, and supporting ITS          |
|               | applications                                         |
|               |                                                      |
|               | ● Spatial data and GIS tools are essential elements  |
|               | of an agency's information technology and ITS        |
|               | infrastructure                                       |
+---------------+------------------------------------------------------+
| > State of    | ● Regional and enterprise-wide GIS systems           |
| > the Art     |                                                      |
|               | ● LIDAR (LIght Detection And Ranging) data, which    |
|               | provide spatial data with x-y-z coordinates          |
|               |                                                      |
|               | ● Internet and desktop tools that provide powerful   |
|               | viewing options of spatial and transit data,         |
|               | including interactive maps                           |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Multiple GIS systems and other barriers limit the  |
| > and Lessons | efficient development, management, exchange, and use |
| > Learned     | of spatial data                                      |
|               |                                                      |
|               | ● Adopt one agency-wide Base Map to maintain and     |
|               | propagate                                            |
|               |                                                      |
|               | ● Integration of both GIS and spatial data efforts   |
|               | can provide some of the biggest integration cost     |
|               | saving benefits in ITS                               |
+---------------+------------------------------------------------------+
| **Com         |                                                      |
| munications** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Provides data and/or voice communications for      |
| > Overview    | transit planning, maintenance, operations, and       |
|               | incident management                                  |
|               |                                                      |
|               | ● Also facilitates coordination with those           |
|               | transportation providers and public safety           |
|               | organizations beyond the transit community           |
|               |                                                      |
|               | ● Encompasses a variety of wireless technologies     |
+---------------+------------------------------------------------------+
| > State of    | ● Applications that provide:                         |
| > the Art     |                                                      |
|               | -   Seamless interoperability between multiple       |
|               |     dissimilar radio systems                         |
|               |                                                      |
|               | -   Reduction of radio channels through increased    |
|               |     use of electronic messaging in lieu of voice     |
|               |     communications                                   |
|               |                                                      |
|               | ● Trends include reforming of radio frequency        |
|               | spectrum, new standards, and use of cellular and     |
|               | wireless Internet services                           |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Recent disasters illustrate need for transit       |
| > and Lessons | communications to interoperate with public safety    |
| > Learned     | and other regional agencies                          |
|               |                                                      |
|               | ● Design constraints limit vendor flexibility in     |
|               | meeting core agency needs and may cost more than     |
|               | they're worth                                        |
|               |                                                      |
|               | ● Make use of wireless Internet cooperative funding  |
|               | opportunities; avoid duplicative deployments         |
+---------------+------------------------------------------------------+
| **Transit ITS |                                                      |
| Standards**   |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● A standard or protocol is a set of rules or        |
| > Overview    | measures to compare or build similar objects. U.S.   |
|               | DOT supports standards to accelerate the             |
|               | development, adoption, and deployment of ITS         |
|               |                                                      |
|               | ● Use of standards lowers costs over the system      |
|               | life; also facilitates integration and               |
|               | interoperability                                     |
+---------------+------------------------------------------------------+
| > State of    | ● Many standards under development; few actually     |
| > the Art     | deployed                                             |
|               |                                                      |
|               | ● Widely implemented standards include SAE J1708 in  |
|               | buses and IEEE 1473 in trains                        |
|               |                                                      |
|               | ● Trend toward greater use of standards              |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Map requirements to standards before specifying    |
| > and Lessons | them in procurements and build on IT standards       |
| > Learned     |                                                      |
|               | ● Regional systems require regional data integration |
|               | strategies                                           |
|               |                                                      |
|               | ● Systems can require multiple standards working     |
|               | together to ensure interoperability                  |
+---------------+------------------------------------------------------+
|               |                                                      |
+---------------+------------------------------------------------------+
| **CHAPTER 3:  |                                                      |
| FLEET         |                                                      |
| MANAGEMENT**  |                                                      |
+---------------+------------------------------------------------------+
| >             | ● Use of technology to plan, supervise, and optimize |
|  Introduction | the delivery of transit services and maintaining     |
|               | vehicles                                             |
|               |                                                      |
|               | ● Technologies are vast and include in-vehicle,      |
|               | field, and operations center systems such as:        |
|               |                                                      |
|               | -   Automatic Vehicle Location                       |
|               |                                                      |
|               | -   Computer-Aided Dispatch                          |
|               |                                                      |
|               | -   Automatic Passenger Counters                     |
|               |                                                      |
|               | -   Transit Signal Priority                          |
+---------------+------------------------------------------------------+
| **Service     |                                                      |
| Planning      |                                                      |
| Support       |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Infrastructure that supports the flow of           |
| > Overview    | information between the various fleet management     |
|               | systems                                              |
|               |                                                      |
|               | ● Processes and interprets large volumes of data for |
|               | reporting purposes                                   |
+---------------+------------------------------------------------------+
| > State of    | ● Accurate accounting and reporting of ridership     |
| > the Art     |                                                      |
|               | ● Automatic reporting of failed equipment            |
|               |                                                      |
|               | ● Automatic calculation of run times for scheduling  |
|               |                                                      |
|               | ● Standards-based modular architecture and           |
|               | multi-vendor component interchangeability            |
|               |                                                      |
|               | ● Trends include map-based tools for maintaining     |
|               | passenger stop and pattern data                      |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Optimizing the reporting capabilities of advanced  |
| > and Lessons | systems to achieve the desired results               |
| > Learned     |                                                      |
|               | ● Efforts to share schedules and stop inventories    |
|               | electronically are hindered by a lack of complete    |
|               | and consistent data                                  |
|               |                                                      |
|               | ● Define an enterprise data model for stop, pattern, |
|               | and schedule information                             |
|               |                                                      |
|               | ● Develop process for data maintenance and updating  |
+---------------+------------------------------------------------------+
| **Transit     |                                                      |
| Priority      |                                                      |
| Treatment**   |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Systems detect approaching transit vehicles and    |
| > Overview    | alter signal (i.e., traffic light) timings to        |
|               | improve transit performance and reliability          |
+---------------+------------------------------------------------------+
| > State of    | ● Intelligent, rule-based systems that determine     |
| > the Art     | need for priority treatment based on many factors    |
|               |                                                      |
|               | ● Trends include advanced systems that manage signal |
|               | priority in an effective manner without disrupting   |
|               | overall traffic flow                                 |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Obtaining support from local traffic engineers     |
| > and Lessons |                                                      |
| > Learned     | ● Lack of funding, technology understanding and      |
|               | inadequate infrastructure capabilities               |
+---------------+------------------------------------------------------+
| **Maintenance |                                                      |
| Management    |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Onboard vehicle component "health" monitoring and  |
| > Overview    | other systems to improve maintenance effectiveness   |
|               | and efficiency                                       |
|               |                                                      |
|               | ● Includes monitoring of fluids, warranty,           |
|               | inventory, and records management; and remote        |
|               | vehicle diagnostics                                  |
+---------------+------------------------------------------------------+
| > State of    | ● Advanced systems that monitor equipment status in  |
| > the Art     | real time and report failures immediately to prevent |
|               | more costly repairs                                  |
|               |                                                      |
|               | ● Automatic transfer of vehicle data as vehicle      |
|               | enters the facility                                  |
|               |                                                      |
|               | ● Single-point-of-maintenance data access for all    |
|               | commuter rail vehicle systems                        |
|               |                                                      |
|               | ● Trends include systems that predict failures in    |
|               | advance                                              |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Tracking and detecting repeat failures; solution   |
| > and Lessons | is to tag field-replaceable units with electronic    |
| > Learned     | serial numbers                                       |
+---------------+------------------------------------------------------+
| **T           |                                                      |
| ransportation |                                                      |
| Operations    |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Agency-based systems that support real-time        |
| > Overview    | operations of transit fleets. Includes:              |
|               |                                                      |
|               | -   Rail Operations Control Center Systems           |
|               |                                                      |
|               | -   Bus Operations Control Center Systems            |
|               |                                                      |
|               | -   Other Operations Systems (ferries, facilities,   |
|               |     HOV, multimodal)                                 |
|               |                                                      |
|               | -   Paratransit Operations Systems                   |
+---------------+------------------------------------------------------+
| > State of    | ● Systems that provide a complete "picture" of the   |
| > the Art     | current status of the entire transit operation       |
|               |                                                      |
|               | ● Trends include:                                    |
|               |                                                      |
|               | -   Integration with passenger information and       |
|               |     maintenance management                           |
|               |                                                      |
|               | -   Use of archived data to facilitate scheduling    |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Inadequate definition of business requirements; be |
| > and Lessons | specific and make priorities understandable          |
| > Learned     |                                                      |
|               | ● Inadequate final acceptance testing of computer    |
|               | systems; develop test plan based on original         |
|               | business requirements                                |
|               |                                                      |
|               | ● Use care when specifying compliance to standards   |
|               |                                                      |
|               | ● Risks associated with custom development           |
+---------------+------------------------------------------------------+
|               |                                                      |
+---------------+------------------------------------------------------+
| **CHAPTER 4:  |                                                      |
| ELECTRONIC    |                                                      |
| FARE          |                                                      |
| PAYMENT**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Provides automated means of collecting and         |
| >             | processing fares for public transportation services  |
|  Introduction |                                                      |
|               | ● Includes:                                          |
|               |                                                      |
|               | -   Fare Systems                                     |
|               |                                                      |
|               | -   Fare Products (Media)                            |
|               |                                                      |
|               | -   Clearinghouse/Regional Service Center (CH/RSC)   |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Difficulty in implementing regional fare           |
| > and Lessons | collection systems due to hardware/software issues   |
| > Learned     | and ineffective working relationships                |
|               |                                                      |
|               | ● Resolve fare policy issues, business rules and     |
|               | revenue reconciliation issues early and in parallel  |
|               | with other activities                                |
|               |                                                      |
|               | ● Involve regional partners in each development      |
|               | stage                                                |
|               |                                                      |
|               | ● Standards help ensure fare integration and         |
|               | interoperability                                     |
|               |                                                      |
|               | ● Have a clear vision of what is expected from an    |
|               | electronic fare system and clearly articulate vision |
|               | and requirements                                     |
+---------------+------------------------------------------------------+
| **Fare        |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Includes various functions and equipment used by a |
| > Overview    | transit agency to deploy a fare collection system    |
+---------------+------------------------------------------------------+
| > State of    | ● Universal electronic fare payment system for       |
| > the Art     | multiple modes                                       |
|               |                                                      |
|               | ● Farebox as single-point logon for bus operators    |
|               |                                                      |
|               | ● Electronic media used for fares and as             |
|               | identification cards                                 |
|               |                                                      |
|               | ● Internet sale of fare products                     |
|               |                                                      |
|               | ● New systems that provide accurate and timely       |
|               | revenue data                                         |
+---------------+------------------------------------------------------+
| **Fare        |                                                      |
| Payment       |                                                      |
| Products      |                                                      |
| (Media)**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Includes magnetic stripe cards, credit cards and   |
| > Overview    | smart cards                                          |
+---------------+------------------------------------------------------+
| > State of    | ● Multifunction, contactless proximity smart cards   |
| > the Art     |                                                      |
|               | ● Limited use (disposable) smart tickets             |
|               |                                                      |
|               | ● Trends include regional, multimodal contactless    |
|               | smart card systems                                   |
+---------------+------------------------------------------------------+
| **Clearingh   |                                                      |
| ouse/Regional |                                                      |
| Service       |                                                      |
| Center        |                                                      |
| (CH/RSC)**    |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Provides a regional fare system with clearing,     |
| > Overview    | settlement and associated financial reports and      |
|               | management information                               |
|               |                                                      |
|               | ● Technology driven by need to provide a high        |
|               | volume, secure transaction processing center         |
+---------------+------------------------------------------------------+
| > State of    | ● Centers having a well-developed and thought-out    |
| > the Art     | institutional framework supported by technology      |
|               |                                                      |
|               | ● Trends include emerging standards that will make   |
|               | regional payment system deployments easier in the    |
|               | future                                               |
+---------------+------------------------------------------------------+
|               |                                                      |
+---------------+------------------------------------------------------+
| **CHAPTER 5:  |                                                      |
| TRAVELER      |                                                      |
| INFORMATION** |                                                      |
+---------------+------------------------------------------------------+
| >             | ● Provides convenient information access to assist   |
|  Introduction | travelers to learn about and use public transit      |
|               |                                                      |
|               | ● Also assists agency staff in locating information  |
|               | to improve transit services                          |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Difficulty in developing accurate, timely and      |
| > and Lessons | complete data                                        |
| > Learned     |                                                      |
|               | ● Allow adequate time to develop needed data         |
|               |                                                      |
|               | ● Well thought-out processes and resources are       |
|               | needed to effectively address ongoing data           |
|               | maintenance needs                                    |
+---------------+------------------------------------------------------+
| **Transit     |                                                      |
| Information   |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Traveler information obtained per trip (to plan a  |
| > Overview    | trip or verify information at trip commencement) or  |
|               | during a trip                                        |
|               |                                                      |
|               | ● Personal systems: information accessed through     |
|               | cell phones, personal digital assistants, and laptop |
|               | computers                                            |
|               |                                                      |
|               | ● In-terminal systems: information provided at bus   |
|               | stops, terminals, train stations, and platforms      |
|               |                                                      |
|               | ● In-vehicle systems: announcements or signs on      |
|               | transit vehicles                                     |
+---------------+------------------------------------------------------+
| > State of    | ● Improved database tools and Web services allow     |
| > the Art     | more specific query options for customers and staff  |
|               |                                                      |
|               | ● New geographic tools and Web mapping allow easier  |
|               | and better querying and displaying of geographic     |
|               | data                                                 |
|               |                                                      |
|               | ● Improved speed and accessibility of wireless       |
|               | communications                                       |
+---------------+------------------------------------------------------+
| **Multimodal  |                                                      |
| Travel        |                                                      |
| Information   |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Makes use of multiple channels (call centers,      |
| > Overview    | kiosks, Internet, telephone, cell phones, PDAs,      |
|               | pagers, etc.) to provide real-time and static        |
|               | information on transit, traffic, and other modes     |
|               |                                                      |
|               | ● Allows travelers to make fully informed mode       |
|               | choice decisions both pre-trip and enroute           |
+---------------+------------------------------------------------------+
| > State of    | ● 511 telephone and Web applications                 |
| > the Art     |                                                      |
|               | ● Advanced trip planning systems to provide best     |
|               | travel options                                       |
+---------------+------------------------------------------------------+
| **Transit     |                                                      |
| Trip          |                                                      |
| Information   |                                                      |
| Inf           |                                                      |
| rastructure** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● "Behind the scenes" tools and procedures to        |
| > Overview    | provide accurate data for trip information services  |
|               | locally and region-wide                              |
+---------------+------------------------------------------------------+
| > State of    | ● Advanced data infrastructures that operate in an   |
| > the Art     | integrated manner, both internally and regionally    |
|               |                                                      |
|               | ● Trends include use of wireless communications, Web |
|               | tools, geographic information, mapping tools and     |
|               | data management techniques to improve traveler       |
|               | information services                                 |
+---------------+------------------------------------------------------+
|               |                                                      |
+---------------+------------------------------------------------------+
| **CHAPTER 6:  |                                                      |
| TRANSIT       |                                                      |
| SAFETY AND    |                                                      |
| SECURITY**    |                                                      |
+---------------+------------------------------------------------------+
| >             | ● Use of technology to improve the safety and        |
|  Introduction | security of transit                                  |
|               |                                                      |
|               | ● Security addresses intentional acts of crime or    |
|               | violence                                             |
|               |                                                      |
|               | ● Safety deals with unintentional harm to people and |
|               | physical assets                                      |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Lack of communications interoperability between    |
| > and Lessons | and among systems due to lack of equipment and data  |
| > Learned     | standards                                            |
|               |                                                      |
|               | ● Populating systems with timely, accurate, and      |
|               | usable data requires leadership to engage regional   |
|               | partners                                             |
|               |                                                      |
|               | ● Also requires sustained commitment to acquiring    |
|               | and maintaining data to effectively manage incidents |
|               |                                                      |
|               | ● Overall plan that clearly identifies               |
|               | responsibilities is crucial in the event of a major  |
|               | safety or security incident                          |
+---------------+------------------------------------------------------+
| **Onboard     |                                                      |
| Safety and    |                                                      |
| Security**    |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Includes onboard voice communications (radio) and  |
| > Overview    | video assessment (camera surveillance) technologies  |
+---------------+------------------------------------------------------+
| > State of    | ● Deployment of "broadband communications corridors" |
| > the Art     | using the Internet to transmit data to and from      |
|               | vehicles; may provide future platform for            |
|               | interoperable voice/data communications              |
|               |                                                      |
|               | ● Limited video advancements onboard transit         |
|               | vehicles; real-time transmission limited to low      |
|               | resolution, black and white images due to bandwidth  |
|               | constraints                                          |
|               |                                                      |
|               | ● Trends include improvements in bandwidth           |
|               | technology to transmit high-density digital video    |
|               | from moving vehicles                                 |
+---------------+------------------------------------------------------+
| > Challenges  | As with all other onboard systems, a major challenge |
| >             | will be to effectively and efficiently integrate     |
| > and Lessons | voice and data systems with other onboard systems    |
| > Learned     |                                                      |
+---------------+------------------------------------------------------+
| **Sta         |                                                      |
| tion/Facility |                                                      |
| Safety and    |                                                      |
| Security**    |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Video assessment systems that monitor activities   |
| > Overview    | at transit stations and facilities                   |
+---------------+------------------------------------------------------+
| > State of    | ● Effective video systems that are well-specified,   |
| > the Art     | deployed, maintained and operated by knowledgeable   |
|               | and engaged users                                    |
|               |                                                      |
|               | ● Trends include making digital video accessible     |
|               | from PCs or PDAs using Internet access protocols     |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Video assessment systems enhance overall safety    |
| > and Lessons | and security programs by providing visual and audio  |
| > Learned     | evidence of incidents                                |
|               |                                                      |
|               | ● New video assessment systems should be integrated  |
|               | with existing administrative and other business      |
|               | systems to enhance overall effectiveness of data     |
|               | collection and analysis                              |
+---------------+------------------------------------------------------+
| **Incident    |                                                      |
| Response**    |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Technologies include chemical detection, Web-based |
| > Overview    | information and radio and cell phone-based           |
|               | communications systems                               |
+---------------+------------------------------------------------------+
| > State of    | ● Significant progress made in testing and deploying |
| > the Art     | chemical detection systems at several major transit  |
|               | systems                                              |
|               |                                                      |
|               | ● National and local 511 efforts are beginning to    |
|               | provide a platform for evacuation information for    |
|               | evacuees                                             |
|               |                                                      |
|               | ● Despite dropped calls and switch capacity          |
|               | constraints that result in busy signals, cell phones |
|               | have become the tenuous means of communicating       |
|               | during an emergency                                  |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Testing procedural aspects of the use of detection |
| > and Lessons | technology are as important as testing the hardware  |
| > Learned     | and software components                              |
|               |                                                      |
|               | ● Getting appropriate, timely information collected, |
|               | assessed, formatted, and transmitted to the affected |
|               | population in an emergency is critical to successful |
|               | technology implementation                            |
|               |                                                      |
|               | ● Radio interoperability for effective               |
|               | communications among emergency responders remains    |
|               | elusive, resulting in dependence on commercially     |
|               | available cell phone technology that does not        |
|               | provide reliable and secure transmission of voice or |
|               | data                                                 |
+---------------+------------------------------------------------------+
| **Incident    |                                                      |
| Management    |                                                      |
| and Planning  |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Provide a way to collect and organize data to help |
| > Overview    | transit agencies make critical incident and disaster |
|               | response management more efficient and effective     |
+---------------+------------------------------------------------------+
| > State of    | ● Limited transit applications to date               |
| > the Art     |                                                      |
|               | ● Trends include live digital video feeds from       |
|               | remote locations overlaid on a geographic map and    |
|               | linked directly into a routing plan for emergency    |
|               | evacuation                                           |
+---------------+------------------------------------------------------+
| > Challenges\ | ● The collection, management and maintenance of data |
| > and Lessons | and information from multiple departments and        |
| > Learned     | agencies require keen leadership and team-building   |
|               | skills, as well as significant staff resources to    |
|               | ensure that data and information are kept up-to-date |
|               |                                                      |
|               | ● Interoperability with other emergency command      |
|               | centers falls short due to the proprietary nature of |
|               | procured systems                                     |
+---------------+------------------------------------------------------+
|               |                                                      |
+---------------+------------------------------------------------------+
| **CHAPTER 7:  |                                                      |
| T             |                                                      |
| RANSPORTATION |                                                      |
| DEMAND        |                                                      |
| MANAGEMENT**  |                                                      |
+---------------+------------------------------------------------------+
| >             | ● Reduces the impact of traffic by influencing       |
|  Introduction | travel behavior                                      |
|               |                                                      |
|               | ● "Big picture" strategic solution for mobility      |
|               | problems that ITS was originally created to address  |
+---------------+------------------------------------------------------+
| **Dynamic     |                                                      |
| Ridesharing** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Paratransit-like service allows travelers to be    |
| > Overview    | joined in real time to provide taxi-like             |
|               | responsiveness                                       |
|               |                                                      |
|               | ● Makes use of many technologies: call centers,      |
|               | Internet-based ridematch, automobiles, and automated |
|               | personal rapid transit                               |
+---------------+------------------------------------------------------+
| > State of    | ● "Next day" responsiveness has been achieved        |
| > the Art     |                                                      |
|               | ● However, "dynamic" ridematching (i.e., pairing     |
|               | riders with hosts in real time) has not yet been     |
|               | successfully implemented                             |
|               |                                                      |
|               | ● Trends include:                                    |
|               |                                                      |
|               | -   Technology improvements that reduce lead time    |
|               |     requirements for trip requests                   |
|               |                                                      |
|               | -   Use of Internet to facilitate statewide          |
|               |     ridematching                                     |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Integrating paratransit with supplemental          |
| > and Lessons | subscription services improves net operating results |
| > Learned     |                                                      |
|               | ● Paratransit vehicles with enhanced systems require |
|               | robust onboard electrical systems                    |
|               |                                                      |
|               | ● Geographic-based software systems require an       |
|               | accurate base map; also need to be maintained on a   |
|               | continual basis                                      |
+---------------+------------------------------------------------------+
| **Automated   |                                                      |
| Service       |                                                      |
| C             |                                                      |
| oordination** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Technologies, policies and procedures that         |
| > Overview    | guarantee passenger transfers during a fully linked  |
|               | trip                                                 |
|               |                                                      |
|               | ● Makes use of automatic vehicle location,           |
|               | electronic fare collection, decision support         |
|               | systems, and mobile data terminals                   |
+---------------+------------------------------------------------------+
| > State of    | ● Current systems use real-time vehicle location     |
| > the Art     | information, but apply simplistic decision tools to  |
|               | protect a particular connection                      |
|               |                                                      |
|               | ● Auto-dial and e-mail notification capability to    |
|               | alert subscribing customers of service disruptions   |
|               | and delays                                           |
|               |                                                      |
|               | ● Trends include next generation of decision-support |
|               | tools to improve connection protection capabilities  |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Complexity makes benefits difficult to achieve and |
| > and Lessons | assess                                               |
| > Learned     |                                                      |
|               | ● Agencies need to gather information on a regular   |
|               | basis to evaluate their effectiveness                |
+---------------+------------------------------------------------------+
| **Multimodal  |                                                      |
| T             |                                                      |
| ransportation |                                                      |
| Management    |                                                      |
| Centers**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Links traffic and transit operations centers to    |
| > Overview    | optimize network performance across multiple         |
|               | transportation modes                                 |
|               |                                                      |
|               | ● Various technologies monitor highway and transit   |
|               | performance, detect congested conditions, notify     |
|               | affected agencies, identify available assets,        |
|               | coordinate a unified response and track results      |
+---------------+------------------------------------------------------+
| > State of    | ● Emergency management centers that combine traffic, |
| > the Art     | transit and emergency planning and management under  |
|               | a single entity                                      |
|               |                                                      |
|               | ● Trends include real-time public transit parking    |
|               | information systems                                  |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Much effort is required to coordinate and maintain |
| > and Lessons | multimodal transportation information at a regional  |
| > Learned     | website                                              |
|               |                                                      |
|               | ● Most project plans have grossly underestimated the |
|               | effort required                                      |
|               |                                                      |
|               | ● The migration to an integrated management center   |
|               | is best made incrementally, one application at a     |
|               | time                                                 |
+---------------+------------------------------------------------------+
|               |                                                      |
+---------------+------------------------------------------------------+
| **CHAPTER 8:  |                                                      |
| INTELLIGENT   |                                                      |
| VEHICLE       |                                                      |
| SYSTEMS**     |                                                      |
+---------------+------------------------------------------------------+
| >             | ● Onboard systems that collect, compare and process  |
|  Introduction | data to inform and/or take corrective action         |
+---------------+------------------------------------------------------+
| > Challenges\ | ● Devices with proprietary interfaces; build careful |
| > and Lessons | controls regarding locally defined codes and data    |
| > Learned     | link escape                                          |
|               |                                                      |
|               | ● Infrastructures or architectures that limit        |
|               | functionality; consider other functions in the       |
|               | design stage                                         |
|               |                                                      |
|               | ● Vehicle networks are best installed during initial |
|               | vehicle assembly                                     |
+---------------+------------------------------------------------------+
| **Intelligent |                                                      |
| Onboard Bus   |                                                      |
| Integration** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Allows various stand-alone equipment found on a    |
| > Overview    | transit bus to interoperate with each other          |
|               |                                                      |
|               | ● Maximizes functionality, reliability, usability,   |
|               | efficiency, and effectiveness of the overall transit |
|               | operation; also reduces costs                        |
+---------------+------------------------------------------------------+
| > State of    | ● Onboard network architecture that provides maximum |
| > the Art     | interoperability and multi-vendor interchangeability |
|               |                                                      |
|               | ● Single-point operator sign-on                      |
|               |                                                      |
|               | ● Trends include migration from application-specific |
|               | networks to IT standards and PC operating systems    |
|               | (e.g., Windows)                                      |
+---------------+------------------------------------------------------+
| **Advanced    |                                                      |
| Vehicle       |                                                      |
| Safety        |                                                      |
| Systems**     |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Collision warning, obstacle detection, road        |
| > Overview    | departure warning, vision enhancement, and other     |
|               | vehicle safety systems                               |
|               |                                                      |
|               | ● Routine in trucking; limited use in transit        |
+---------------+------------------------------------------------------+
| > State of    | ● Single reported U.S. transit application includes  |
| > the Art     | side collision warning system                        |
|               |                                                      |
|               | ● Trends include increased penetration of these      |
|               | available technologies to transit vehicles           |
+---------------+------------------------------------------------------+
| **Vehicle     |                                                      |
| Guidance      |                                                      |
| /Automation** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Navigation and route guidance systems, precision   |
| > Overview    | docking systems, adaptive cruise control systems,    |
|               | and coupling/decoupling systems to reduce driver     |
|               | workload                                             |
+---------------+------------------------------------------------------+
| > State of    | ● Single reported U.S. transit application includes  |
| > the Art     | precision bus docking application for platform-level |
|               | boarding                                             |
|               |                                                      |
|               | ● Trends include electronic lane-keeping assistance  |
|               | systems                                              |
+---------------+------------------------------------------------------+
| **Intelligent |                                                      |
| Rail Vehicle  |                                                      |
| Integration** |                                                      |
+---------------+------------------------------------------------------+
| > Technology  | ● Allows various stand-alone equipment found on a    |
| > Overview    | railcar or locomotive to interoperate with each      |
|               | other                                                |
|               |                                                      |
|               | ● Maximizes functionality, reliability, usability,   |
|               | efficiency, and effectiveness of the overall         |
|               | transit; also reduces costs                          |
+---------------+------------------------------------------------------+
| > State of    | ● Multi vendor interchangeability of radio systems,  |
| > the Art     | event recorders, mechanical components and others    |
|               |                                                      |
|               | ● Interchangeability extended to car-borne control   |
|               | and information systems to allow higher level of     |
|               | interoperability                                     |
|               |                                                      |
|               | ● Trends include standards for sign and voice        |
|               | annunciator systems                                  |
+---------------+------------------------------------------------------+

# Chapter 1 Introduction

## 1.1 Background {#background .Style-Heading-2-+-Justified}

This report documents work performed under the FTA's Advanced Public
Transportation Systems (APTS) Program, a program structured to undertake
research and development of innovative applications of advanced
navigation, communication, information, computer, and vehicle
technologies that most benefit public transportation.

***The Advanced Public Transportation Systems State of the Art Update
2006*** *[(APTS SOA]{.underline}* *[Update 2006)]{.underline}* is the
seventh in a series of ongoing informational reports, the last of which
was published in December 2000. It summarizes the results of a limited
investigation on the progress of implementing Advanced Public
Transportation Systems technologies throughout the nation. The objective
of the report is to provide information that will lead to an enhancement
of the public transportation industry's knowledge on the application of
advanced technologies.

This report was conducted by the Palisades FTA Omni Team and was
sponsored by the Office of Mobility Innovation of the Federal Transit
Administration.

## 1.2 New Report Approach {#new-report-approach .Style-Heading-2-+-Justified}

A new approach was taken for this edition to provide a useful and timely
reference on the subject of emerging transit ITS technological advances
and trends. Efforts focused on highlighting successful ITS applications,
revealing the lessons learned along the way, and identifying the issues
and hurdles to help other agencies replicate SOA applications in an
efficient and successful manner.

A substantial effort was made to seek out, survey, and interview
knowledgeable transit personnel and to document the findings and
recommendations for national policy as well as specific types of federal
technical assistance. The report describes some of the newest
technologies and provides real-world examples of state-of-the-art
applications of those technologies. Challenges and lessons learned are
documented and conclusions are drawn to provide input to FTA for its
transit ITS planning and programming assistance efforts.

## 1.3 Defining "State of the Art" {#defining-state-of-the-art .Style-Heading-2-+-Justified}

For this report, the research team identified "state-of-the-art
technologies" in both objective and subjective terms. Technologies were
selected for inclusion in the report based on combined criteria such as
a technology's newness, best application, best business results, and
greatest potential. As a result, the report reflects, in good measure,
the "state of the art" in defining and interpreting the "state of the
art" in Transit ITS.

## 1.4 New Typology Organization {#new-typology-organization .Style-Heading-2-+-Justified}

In the past, the Federal Transit Administration (FTA) has supported the
development of ITS typologies, which organize and classify the various
ITS applications in transit. Over time, the typologies require updating
to incorporate the various changes and advances as ITS developments are
refined and new ITS efforts emerge.

The *APTS SOA Update 2006* is based on a revised and expanded ITS
typology (subject classification system). The updated typology
classification builds upon past typologies and considerations for other
typology efforts currently under way, and provides the report with a
cogent framework to highlight successful ITS applications, reveal the
lessons learned along the way, and identify the issues and hurdles to
help other agencies replicate SOA applications in an efficient and
successful manner.

The SOA 2000 report typology featured five major categories, which have
been expanded to seven for the SOA 2006 report (See Figure 2). To refine
the typology, past transit ITS typologies were reviewed with respect to
each other, and considerations were given to other typology development
efforts under way and to recent ITS advances and issues. The report
typology used the following objectives as guidance:

> Establish a simple, clear method to classify the ITS elements with the
> least amount of redundancy;
>
> Ensure that the approach established to classify ITS is consistent
> with:
>
> Transit organizations and their glossary,
>
> National ITS Architecture categories, and
>
> FTA benefits and program categories;
>
> Incorporate new advances in ITS technologies since the last SOA Report
> and support changing transit business processes; and
>
> Support information consistency and transferability with prior SOA
> reports and the ITS Impact Matrix typology.

[]{#__RefHeading___Toc129324144 .anchor}Figure 2 Recommended Transit ITS
Typology

![](media/image10.wmf)

Central to the typology of this report is the new category titled
"Integration," which includes communication, architecture, standards
infrastructure, data, emerging technologies, and business processes and
software needed to successfully implement transit ITS. The importance of
this topic is such that it deserves its own place as a central typology
category, linking all agency ITS applications into an integrated system
that allows it to operate and provide passenger services more
efficiently, and to exchange data with other transit agencies and
transportation providers. This new category not only addresses
integration within transit itself, but serves to link transit with
other, more universal transportation providers.

Integration encompasses the ITS National Architecture and ITS Standards,
as well as core elements of a successful transit ITS infrastructure. The
subject of information technologies (IT) is also addressed to highlight
the importance of accurate, timely agency-wide data. Like the previous
typologies, each of the major categories contains subcategory branches
with specific applications. Since integration is essential to ITS in
that it facilitates a "system" of interconnected ITS applications that
collectively produce services and advantages far greater than
independent ITS applications could achieve, it is placed as the
centerpiece of the ITS typology and links the other six major
categories.

Transit Safety and Security, which addresses the systems and
technologies that deal with the safety and security of transit
customers, personnel, equipment, and facilities, has been expanded to
address Disaster and Incident Management Planning Support Systems. Other
significant changes to the recommended typology include new nomenclature
to reflect recent ITS developments, understandings, and terminologies.
Also included are new or retitled subcategories that address many of the
important but often overlooked programs, support systems, and business
processes that have been kept "hidden" in previous ITS typologies.

## 1.5 Intended Audience {#intended-audience .Style-Heading-2-+-Justified}

The intended audience for this report consists of transit decision
makers and management staff.

## 1.6 Report Objective and Methodology {#report-objective-and-methodology .Style-Heading-2-+-Justified}

### 1.6.1 Report Objective {#report-objective .Style-Heading-3-+-Justified}

The capabilities of ITS greatly exceed the current practice and will
continue to do so as new technology applications are discovered. The
purpose of this report is to help agency decision makers keep pace with
ITS by focusing on state-of-the-art applications, and the challenges and
lessons learned from those applications (not on state-of-the-practice,
as this information is available in other reports). The report is
intended to give agencies a better understanding of:

> The various major technologies that make up ITS;
>
> The capabilities and limitations of those technologies;
>
> Exemplary successes achieved by those agencies that represent the
> state of the art in ITS deployments;
>
> The lessons learned along the way and the obstacles conquered to
> achieve those successes;
>
> The issues and hurdles that agencies need to overcome themselves to
> help streamline ITS deployments; and
>
> What the future holds for major ITS technologies.

### 1.6.2 Report Methodology {#report-methodology .Style-Heading-3-+-Justified}

The revised ITS typology for this report, which captured all significant
ITS applications and is consistent with industry efforts to standardize
ITS classifications, provided the framework for the report structure and
subsequent project research and information- gathering activities.

The research team reviewed relevant literature published during the last
two years which included relevant material on ITS technological
advances, recent procurements and deployments of ITS systems,
integration of ITS technologies, intermodal applications, and
interagency coordination of ITS technologies. Materials reviewed
included but were not limited to materials already developed by USDOT
and FTA and information from publications and websites available from
the American Public Transportation Association (APTA), ITS America, the
Transportation Research Board (TRB) and others.

Appropriate personnel at the FTA regional offices were contacted for
their input regarding agencies with SOA deployments. Press releases
announcing the SOA report were sent to trade publications as another
method of soliciting SOA information from the transit community, and an
online survey questionnaire was distributed to more than 1,800 transit
professionals; responses from more than 40 professionals provided
information to the research team (see Appendices A and B).

Based on the literature review, responses to the survey questionnaire,
and the research team's own understanding of ITS, information was
summarized and synthesized under the major ITS typology groups as
defined for this report, and a minimum of three transit agencies were
identified with state-of-the-art deployments. Transit agency experiences
remained the focus. Vendor names with advanced ITS technologies or
applications were not used to avoid the potential of appearing to
promote one product over another; however, vendors were interviewed to
provide their perspective concerning the issues and hurdles associated
with ITS implementations.

## 1.7 Report Organization {#report-organization .Style-Heading-2-+-Justified}

This report focuses on seven types of services/technologies:
Integration, Fleet Management, Electronic Fare Payment, Traveler
Information, Transit Safety and Security, Transportation Demand
Management, and Intelligent Vehicle Systems.

For each of the ITS typology categories, concise overviews of APTS
technologies are provided and current state-of-the-art and emerging
trends, state of the practice, and challenges and hurdles to
implementation are discussed.

# Chapter 2 Integration 

## 2.1 Introduction and Technology Overview  {#introduction-and-technology-overview .Style-Heading-2-+-Justified}

Now that transit agencies are implementing multiple ITS technologies and
regional ITS projects are being deployed, consideration of integration
issues and the development of integration strategies is of critical
importance. If a transit agency is to reap the full benefits of its
investments in ITS and avoid unnecessary or redundant use of resources,
the agency must consider integration options to ensure a sound
information technology infrastructure, successful ITS projects, and
reasonable ongoing maintenance requirements.

This chapter will cover a wide range of possible integration
opportunities and strategies that can benefit transit agencies and their
customers. For example, it will discuss integration with respect to:

> Regional ITS Architectures;
>
> Enterprise Architectures and other information technology systems;
>
> Data management;
>
> Geographic Information Systems (GIS);
>
> Communications;
>
> ITS standards;
>
> Management support; and
>
> Policies and procedures.

Integration, when implemented from an enterprise-wide perspective and a
regional perspective when appropriate, improves the overall usability of
a technology environment made up of products from many different vendors
on multiple platforms and data from many different systems. Integration
is also valuable to transit ITS in that it facilitates a "system" of
interconnected ITS applications that collectively produce services and
advantages far greater than the ITS applications could achieve
independently.

### 2.1.1 Need for Integration {#need-for-integration .Style-Heading-3-+-Justified}

The need for integration of transit data and ITS systems is driven by
many factors. First and foremost, transit customers are best served by
seamless travel options and information as they traverse between the
various travel modes and transit providers. Transit technology personnel
also need some level of systems and data integration to ensure
interoperable and supportable systems. Budget and funding constraints
also drive the need for minimal redundancy and greater efficiencies.

To improve the effectiveness of the overall transit operation, each
staff member must have access to information in a transparent and
seamless fashion, despite the fact that information needed by transit
business users is often spread throughout various business applications
in different agency departments. Without an integrated approach to
creating, managing, analyzing, and accessing information, obtaining
needed information can be slow, costly, and at risk. This is especially
true if only a few key staff know how to access that information.

In addition, to facilitate the integration of transportation services
and the leveraging of resources, the U.S. Department of Transportation
(USDOT) has implemented policies, rules, and programs to guide and
support transit's integration efforts.

Opportunities for reaping benefits through integration, sharing
communications resources, and leveraging investments abound in ITS and
transit. Figure 3, taken from a report by Oak Ridge National
Laboratories[^1] on shared ITS communications involving transit,
displays the many locations throughout the U.S. where transit
organizations have shared one or more of the following:

> ITS technologies;
>
> Telecommunications infrastructure;
>
> Bandwidth;
>
> Information;
>
> Facilities; and
>
> Personnel.

Through this networking, transit agencies and their customers have
realized benefits from integrating or sharing information and systems
technologies with other ITS applications, departments, transit agencies,
DOTs, toll agencies, cities, counties, government councils, utilities,
emergency service organizations, private agencies, and others.

[]{#__RefHeading___Toc129324145 .anchor}Figure 3 Locations with Shared
ITS-Related Resources

![](media/image11.jpeg){width="6.010416666666667in" height="4.3125in"}

From "Shared Communications: Volume I. A Summary and Literature
Review"[^2]

### 2.1.2 Integration Subcategories {#integration-subcategories .Style-Heading-3-+-Justified}

This section on integration focuses on the topics shown in Table 2 that
cut across all areas of ITS, including ITS architecture, enterprise
data, Geographic Information Systems (GIS), communications, and transit
ITS standards.

[]{#__RefHeading___Toc129324322 .anchor}Table 2 Integration
Subcategories

  -----------------------------------------------------------------------------
  **\#**    **Subcategories**    **Description**
  --------- -------------------- ----------------------------------------------
  **2.2**   **Transit ITS        Processes, procedures, and benefits that
            Architecture**       relate to the National ITS Architecture and
                                 compliance with the FTA Policy. Also includes
                                 agency level IT/ITS architectures and project
                                 architectures.

  **2.3**   **Enterprise Data**  Includes discussion of the data infrastructure
                                 necessary to support a modern transit agency,
                                 including archived data as well as real-time
                                 operating data and spatial data.

  **2.4**   **Geographic         The software, hardware, and data that are
            Information Systems  needed to create and manage spatial data,
            (GIS)**              perform spatial analyses, produce maps, and
                                 distribute spatial data sets. This tool has
                                 application throughout the transit
                                 organization, including for communicating with
                                 customers, regional partners, and other
                                 stakeholders.

  **2.5**   **Communications**   Media and equipment used for voice
                                 communications and/or data transfer for
                                 transit operations, and for communicating with
                                 customers and regional partners.
                                 Communications systems support onboard,
                                 mobile, and fixed-end equipment and
                                 applications.

  **2.6**   **Transit ITS        Information technology (IT) and intelligent
            Standards**          transportation system (ITS) standards relevant
                                 to the deployment of transit ITS.
  -----------------------------------------------------------------------------

If architecture planning and a range of integration strategies are not
in place, transit agencies face greater challenges in integrating
disparate ITS systems, databases, communications systems, and other
automated systems into a single enterprise-wide business support
infrastructure. Furthermore, they may miss opportunities to leverage
resources, improve service quality, simplify maintenance requirements,
and avoid redundant efforts (e.g., paying for and implementing redundant
hardware, software, and databases).

A well-conceived communications infrastructure is absolutely critical to
the successful systems integration and implementation of ITS
applications, including communicating between systems and modes within a
transit agency, and communicating with external stakeholders such as
customers and other transportation providers. Adequate communications
and network capacity must be available when new ITS applications are
implemented or the resulting "slow access to data can stall critical
operations and cause recurring costs in lost productivity."[^3]
Communications-related planning also helps to avoid unnecessary
redundant costs and labor, such as the possibility of placing multiple
antennas, wiring harnesses, and other equipment onboard vehicles to
support multiple ITS projects such as Automated Passenger Counters (APC)
and Automated Vehicle Location (AVL). Finally, opportunities for cost
sharing and better incident management can occur when communications
integration exists with emergency services organizations.

GIS and Enterprise Data are critical for supporting most ITS
applications and decision- making functions. Core data, such as bus
stop, schedule, and route location information, are used enterprise-wide
by multiple systems and functions. Time and cost efficiencies, as well
as service quality improvements, are possible when core data is created,
managed, analyzed, and distributed with an integrated, enterprise-wide
perspective. This approach can minimize problems such as having to do
follow-up field collection of bus stop data, having incompatible base
maps, manually doing multiple updates of the same route data in
different databases, having to learn and support too many ad hoc
analysis and reporting tools, and many other issues.

This chapter specifically focuses on the:

Benefits to transit agencies resulting from integration and using the
National ITS Architecture and ITS Standards;

-   Overview and description of the National ITS Architecture and
    Transit ITS Standards;

Information Technology and ITS architectures internal to transit;

Use and benefits of systems engineering principles;

The importance of communications in ITS systems integration;

Roles of an agency-wide GIS and Enterprise Data in supporting and
integrating ITS applications and minimizing redundant data maintenance
efforts; and

SOA integration examples.

### 2.1.3 Institutional Support of Integration and Sharing {#institutional-support-of-integration-and-sharing .Style-Heading-3-+-Justified}

For ITS projects to be successful, integration must occur on many
fronts. Hardware, software, data, and communications are typically the
focus of integration efforts. However, management support, institutional
relationships, and communications must also be in place. Numerous ITS
assessments have identified the importance of managing "people and
process" issues and other institutional considerations.[^4]

Managing relationships between business entities is an important aspect
of managing "people and processes." If a relationship between two
operating entities does not exist prior to ITS technologies being
deployed, then one will not necessarily work just because agencies
purchase expensive hardware, design and install software, create data,
and build interfaces. In fact, implementing an ITS project can strain an
existing relationship between two entities because it will probably
require compromises from both parties on everything from determining
functional specifications to defining the criteria for success.

Critical success factors for integration include:

> ITS architecture planning at both the agency and regional levels;
>
> Management leadership to encourage work groups to have a broader
> agency-wide perspective than their own business area or ITS project;
>
> The disciplined use of a systems engineering approach;
>
> Appropriate investment levels to support enterprise data management
> and a technology infrastructure; and
>
> The application of integration-related policies, technical principles,
> and standards.

## 2.2 Transit ITS Architecture  {#transit-its-architecture .Style-Heading-2-+-Justified}

The U.S. Department of Transportation (USDOT) recognized the need to
integrate transportation services between modes and regionally to
benefit customers and to leverage resources. To help facilitate
integrated transportation services and ITS systems, the USDOT invested
in a number of initiatives such as the development of the National ITS
Architecture, a National ITS Architecture Consistency Policy for Transit
Projects, and a similar Rule for the Federal Highway Administration.[^5]

The National ITS Architecture is a framework for developing integrated
transportation systems. An "architecture" helps define all the key
components of what is being built and how they all relate to one
another. Standards and protocols help ensure that all the components
"fit" together, ideally in an organized and efficient manner. In
particular, the National ITS Architecture addresses both logical and
physical architecture elements.[^6] A logical architecture focuses on
the functional processes and information flows of a system. A physical
architecture takes the processes identified in the logical architecture
and assigns them to physical entities (called subsystems in the National
ITS Architecture). The National ITS Architecture helps identify
processes and data flows among ITS subsystems and centers. Further, it
serves as a resource for developing regional and project architectures.

Additional discussion of the FTA policy, including the regional ITS
architecture and systems engineering provisions, is included in Section
2.2.1 below. A discussion of standards is included in Section 2.6.

### 2.2.1 Technology Description {#technology-description .Style-Heading-3-+-Justified}

Three levels of Transit ITS Architectures can support each other and
contribute to the success of ITS. Transit ITS architectures can be:

-   Regional ITS Architectures that show high level ITS relationships
    with ITS efforts in other agencies, or other aspects of ITS such as
    Emergency Management or Traffic and Travel Management;

> Agency-specific IT/ITS architectures; and
>
> ITS project architectures.

The FTA ITS Policy that guides use of the National and Regional ITS
Architectures is described in Section 2.2.1.1. Regional ITS
Architectures are briefly described in 2.2.1.2. An important element of
the FTA ITS Policy that helps drive the success of ITS implementation
efforts is the systems engineering requirements, which are discussed in
Section 2.2.1.3. Transit Internal Architectures are described in Section
2.2.1.4.

#### 2.2.1.1 FTA Policy {#fta-policy .Style-Heading-4-+-Justified}

A relatively recent FTA policy affects transit procurements and
implementations of ITS applications. On April 8, 2001, FTA's National
ITS Architecture Consistency Policy for Transit Projects went into
effect. As of April 8, 2005, this policy requires that all ITS projects
funded by the Highway Trust Fund and the Mass Transit Account must be
part of a regional ITS Architecture, use a systems engineering approach
during development, and use ITS standards adopted by USDOT.[^7] The
policy stipulates that:

> *The final design of all ITS projects funded with highway trust funds
> shall accommodate the interface requirements and information exchanges
> as specified in the regional ITS architecture. If the final design of
> the ITS project is inconsistent with the regional ITS architecture,
> then the regional ITS architecture shall be updated.*

The goals of the ITS Architecture Policy are to:

-   Facilitate seamless travel in a region by improving integration
    between travel modes and service providers;

> Increase regional information sharing to support public
> transportation;
>
> Reduce design costs and development times for new systems;
>
> Lower risks;
>
> Leverage funding in a region; and
>
> Prepare for future expansion.

#### 2.2.1.2 Regional ITS Architecture {#regional-its-architecture .Style-Heading-4-+-Justified}

Key aspects of developing the Regional ITS Architecture include
collaboration among internal and external organizations, and the
building of the regional architecture based on the National ITS
Architecture. The National ITS Architecture identifies transit
"processes" (which are bundled into equipment and market packages) as
building blocks of the multimodal transportation system. Transit
linkages to other "processes" are identified and highlight transit's
integral role in the regional transportation network.

A key provision of the regional planning process is to identify what and
how information is shared among transportation organizations and
stakeholders. The full benefits of ITS are realized with the integration
of regional-wide data. Elements of the Regional ITS Planning Process
include the need to:

-   Identify regional stakeholders and ITS inventory;

> Identify needed transportation services;
>
> Identify WHO needs to exchange information;
>
> Identify WHAT information needs to be exchanged;

-   Identify transit needs and opportunities for data integration in
    joint ITS projects; and

> Define agreements.

#### 2.2.1.3 Systems Engineering Requirements and Procurement Implications {#systems-engineering-requirements-and-procurement-implications .Style-Heading-4-+-Justified}

In addition, to be in compliance with the Policy, all eligible ITS
projects are required to be developed with the use of a systems
engineering approach that includes the following elements:

-   A description of the scope of the ITS project;

-   An operational concept that identifies the roles and
    responsibilities of participating agencies and stakeholders in the
    operation and implementation of the ITS project;

-   Functional requirements of the ITS project;

-   Interface requirements and information exchanges between the ITS
    project and other planned and existing systems and subsystems; and

-   Identification of applicable ITS standards.

A number of resources are available to assist agencies with the systems
engineering process. One example is a "Systems Engineering Guidebook for
ITS" sponsored by the Federal Highway Administration (FTA) and the
California Department of Transportation. In addition, Section 8 of the
\"Location Referencing Guidebook"[^8] contains information to help
agencies comply with the FTA National ITS Architecture Policy on Transit
Projects, particularly the systems engineering aspects that pertain to
spatial data sharing. Strict adherence to systems engineering practices
will help accomplish five key activities that significantly impact a
project's success[^9]:

1.  Identify and evaluate alternatives;

2.  Manage uncertainty and risk in systems design and implementation;

3.  Design quality into systems;

4.  Control "life cycle" costs of a project; and

5.  Handle program management issues as they arise.

FTA's National ITS Architecture Policy on Transit Projects reinforces
the need for collaboration on procurement efforts among key stakeholders
such as IT, the business client, other ITS participants, legal and
procurement staffs, and regional partners. The Policy also emphasizes
that roles and requirements pertaining to the development and/or
maintenance of data or systems need to be defined. In addition,
procurements of affected transit ITS applications will also require that
more attention be directed to standards.

#### 2.2.1.4 Transit Internal Architecture  {#transit-internal-architecture .Style-Heading-4-+-Justified}

At the transit agency level, the ITS Architecture should be integrated
with the transit agency's Information Technology (IT) Architecture. ITS
applications use many of the agency's IT components such as agency core
data (e.g., schedule data, bus stop information, operator IDs, spatial
data), local area networks (LAN), wide area networks (WAN), database
management systems, ad hoc reporting software, servers, and other
hardware and software. If significant changes to either the IT and/or
ITS systems and infrastructure are not coordinated, system failures or
unwanted interference might occur. For example, adding the massive data
flows from a new AVL system to an agency's WAN/LAN can cause performance
issues if the network capacity is not designed to handle the additional
communications load.

Agencies with state-of-the-art strategic planning processes apply a
method known as Enterprise Architecture Planning, or EAP,[^10] to help
improve the success and cost effectiveness of IT and ITS investments.
The Federal Chief Information Officers (CIO) Council (1998) approved
EAP, and the Federal Enterprise Framework was established in 1999 to
promote shared development, interoperability, and sharing of information
for federal agencies and other government entities.[^11] The Office of
Management and Budget (OMB) released its *OMB Enterprise Architecture
Assessment Framework (December 2005)* to help improve performance of
technology investment decision making through the alignment of EAP with
management processes including strategic and capital planning and
program/project management.  The term "enterprise," while understood in
the context of the overall transit organization, transcends the
established organizational boundaries to include external stakeholders.
For example, a transit agency's enterprise IT/ITS architecture may
include a data exchange mechanism with an adjacent transit agency or a
metropolitan planning organization.

Based on the EAP methodology, business goals and needs should drive the
implementation of technology. Therefore, an understanding of the transit
business environment is necessary to properly align the integration
strategies and technology choices to the business. Elements of the
business environment that drive the technology investment include the
mission, vision, goals, guiding principles, and critical success
factors. Consideration of stakeholders and stakeholder needs influence
the development of the goals, objectives and system requirements.

When EAP is made part of the agency's strategic planning and management
processes, it establishes an agency-wide roadmap to help the agency
achieve its mission by supporting optimal performance of its core
business processes within an efficient information technology
environment. EAP becomes a method for defining an organization's current
(baseline) systems and technology environment, desired (target)
environments, and transition strategy. It is essential for evolving
information systems and inserting emerging technologies such as ITS that
optimize mission value.

EAP also supports the process of defining architectures and developing
blueprints for the use of information in support of the business and the
plan for implementing those architectures. It provides the framework to
begin the definition of documented and coordinated structures for
cross-cutting business needs and design developments, and support
collaboration among the divisions for increased efficiency and improved
services to the transit customer.

The adoption of explicit standard-oriented policies and guidelines,
established in compliance with technology principles, is fundamental to
the EAP process.

### 2.2.2 State of the Art {#state-of-the-art .Style-Heading-3-+-Justified}

The implementation of regional ITS architectures, agency IT/ITS
architectures, and project architectures has contributed to the success
of ITS implementations, the leveraging of transit resources, the
minimization of duplication, and offers a greater degree of seamless
transit services for customers. The architecture development process has
provided a forum for agency staff to share information, learn about
collaboration and integration opportunities, and improve planning. The
architecture development effort also helps with understanding the
driving forces behind business processes, organizational roles,
responsibilities, strengths, strategies, issues, and needs. The process
is as important as the outcome.

Most regions of the U.S. have now completed regional ITS architectures,
and a number of deployment statistics and reports are available to the
transit industry.[^12] Examples include national summary reports, survey
summary reports, metropolitan area reports, and medium city reports. In
addition to the USDOT's Web page on deployment reports and statistics,
the USDOT has an Examples Web page[^13] that provides linkages to
examples from existing regional ITS architectures that follow the
development process described in the Regional ITS Architecture Guidance
Document.[^14] Examples are included for the six major steps in
developing a regional architecture: Get Started, Gather Data, Define
Interfaces, Implementation, Use the Regional Architecture, and Maintain
the Regional Architecture.

Below are some examples where benefits have occurred from implementing
regional ITS architectures, internal IT/ITS architectures, or project
architectures.

-   The Metropolitan Transportation Commission (MTC), representing the
    San Francisco Bay area, has implemented a regional architecture that
    facilitates the development of integrated, regional ITS applications
    such as GIS services, Trip Planning support, and others.

-   The Iowa DOT has set the stage for the implementation of a statewide
    Automated Vehicle Locator/Global Positioning System (AVL/GPS) in the
    Iowa public sector. The DOT serves as the consortium manager for the
    project and sets contracting standards on behalf of approximately
    sixteen transit systems in Iowa. The ITS architecture process helped
    prioritize transportation problems, helped identify stakeholders in
    the state with common needs, and assisted with coordinating ITS
    activities in different regions in the state.[^15]

-   The Los Angeles County Metropolitan Transportation Authority
    (LACMTA) has an Arterial ITS Inventory and Architectural Project
    that is guiding ITS investments. In addition, LACMTA has developed a
    regional project architecture for its electronic fare collection
    project, enabling multiple transit agencies in the region to
    participate at a lower cost and providing customers with a more
    seamless fare paying experience.

-   A comprehensive IT/ITS architecture and strategic planning effort
    was completed with broad staff participation at Miami-Dade Transit
    (MDT) to help guide the IT and ITS investments at MDT. The effort
    helps staff to understand project dependencies and priorities, and
    identify key stakeholders and opportunities for leveraging
    investments and other benefits.

### 2.2.3 Emerging Trends {#emerging-trends .Style-Heading-3-+-Justified}

The South Carolina Department of Transportation (SCDOT) is coordinating
a statewide technology infrastructure for paratransit and
demand-response transit in both urban and rural areas. Applications will
be centrally hosted, and each regional transit authority will access and
use applications via its Web browser.

The Town of Chapel Hill in North Carolina is setting the stage for
implementing a new portion of its regional architecture. It is planning
to implement a real-time passenger information system that potentially
can be implemented by other transit agencies in the Triangle Region.

An ITS project architecture was developed for an "Illinois Transit Hub"
in the Gary, Chicago, Milwaukee region. The role of the Illinois Transit
Hub is to serve as a collection and distribution point for transit ITS
data, and to support value added systems such as transfer connection and
certain traveler information facilities.

### 2.2.4 Challenges and Lessons Learned {#challenges-and-lessons-learned .Style-Heading-3-+-Justified}

Several challenges and lessons learned pertaining to the development and
use of architectures to integrate ITS technologies were identified. They
are summarized below.

1.  Although transit agencies send staff to participate in the
    development of the regional architecture, many transit staff that
    work on ITS projects are often unaware of the details of the
    regional architecture.

2.  In areas where regional travel can occur across a number of
    metropolitan areas (such as the New York, New Jersey, and
    Philadelphia areas), some coordination across regional architectures
    may be needed.

3.  Many of the largest integration benefits for transit occur internal
    to their agency, not just with other regional partners.

4.  The National ITS Architecture has added more detail internal to the
    transit ITS applications to help transit agencies identify and
    obtain integration benefits.

5.  The ITS architecture for a transit agency needs to be closely linked
    to the transit agency's IT architecture. ITS applications have a
    high dependency on the agency's IT data model, database management
    system, network capacity, and other IT components.

6.  The systems engineering component to FTA's Policy on the National
    ITS Architecture is extremely important when developing ITS
    projects. In fact, it becomes an essential component at all stages
    of the project's life cycle.

7.  Key to the successful deployment of ITS technologies is to have the
    agency's goals drive the information and technology investments.
    These goals should also be reflected in the various architectures.

8.  To ensure long-term benefits to transit agencies and their
    customers, transit staff needs to develop strategies for sharing
    data resources and data maintenance activities with external
    organizations. Furthermore, agencies should *establish formal
    agreements* on the communications, security, data management, and
    information exchange requirements for all interfaces and the
    resources needed to implement those interfaces.

9.  The lack of an onboard architecture can be an issue for transit
    vehicles when ITS components are added to the vehicle. Significant
    planning and integration is needed to ensure the necessary and
    efficient flow of data between the onboard ITS components and the
    back-office environments. Often, the process to ensure the flow of
    data has fallen between the cracks of the IT organization, the bus
    procurement group, vehicle maintenance, and engineering. To ensure
    that this does not happen, multidisciplinary skills and
    cross-organization coordination are needed for the success of ITS
    applications with respect to onboard components.

10. Integration of technology cannot occur without the integration of
    business objectives and policies of the departments and/or agencies
    that are expected to cooperate in an ITS project.

## 2.3 Enterprise Data {#enterprise-data .Style-Heading-2-+-Justified}

ITS systems require accurate data to operate effectively. They also
typically need to receive and share data with other transit agency
information technology (IT) and ITS systems and databases. In a number
of implementations, the ITS systems must also share data with legacy
systems such as human resource systems. Some ITS systems, such as APC
systems, need to manage potential large volumes of ITS information and
require methods for data creation, storage, update, maintenance,
analysis, and distribution. ITS projects may never operate efficiently
and effectively if required data sets are not integrated and maintained
properly.

Enterprise data are the set of core data that describe the service
provision, operating environment, assets, operations, and maintenance
information, and are shared by multiple organizational units and
applications throughout the transit agency. Business sub-areas may have
their own internal sets of core data. The core data include data sets
used by planning, service planning, asset and maintenance management
(for automatic vehicle monitoring), fare and ridership, risk management,
security, customer information and marketing, and many other areas. Core
data may be generated by, or flow through, customer and back-office
systems, field systems, or onboard transit revenue and non revenue
vehicles. Core data have a life cycle, and exist in different versions
over time.

By managing core service and operational data from an integrated,
enterprise-wide perspective, a transit agency can more cost effectively
realize the benefits of ITS investments, reduce duplicative data
maintenance efforts, and avoid potentially embarrassing data
inconsistencies that require troubleshooting and resolution efforts.
Additional efficiencies can also be realized when disparate service and
operational data sets from various parts of an organization and ITS
systems are integrated and fused into key performance indicators, and
then analyzed over time to support informed decision making. Finally,
ITS implementation project delays and cost overruns due to data issues
can be minimized or avoided if the agency's implementation plan includes
provisions for factoring in the time needed and the project dependencies
associated with defining data requirements and data relationships and
completing data development.

### 2.3.1 Technology Description {#technology-description-1 .Style-Heading-3-+-Justified}

The technologies that support the development of the enterprise data are
relatively straightforward and consist of:

> **Transit Agency Data:** Core data sets that are shared and used by
> many organizational units within the agency. These data may be
> maintained over time, flow through several applications, and pass
> through a life cycle.
>
> **Transportation Network:** Geographic Information Systems (GIS) data
> including the street network, landmarks, address attributes, place
> names, and other geospatial data sets upon which the transit network
> and applications may be built. GIS data will be discussed in more
> detail in Section 2.4, GIS.
>
> **Database Management System (DBMS), data management, and reporting
> tools:** In additional to a DBMS, there are several data management
> and reporting tools that will help transform legacy data, clean and
> aggregate data for warehousing, and develop complex reports from
> distributed databases throughout the organization.
>
> **Distributed Logical Data Model:** Similar to a framework or plan,
> the logical data model describes the data, its format, semantics, and
> relationship to other data concepts. The logical data model is one of
> the key technologies that provides a roadmap for building and evolving
> the enterprise data infrastructure.
>
> **Data Policies and Procedures**: Policies and procedures are used for
> accessing, creating, describing, updating, deleting, and providing
> resources to maintain data sets across an organization. Data policies
> and procedures are typically developed by a data committee that
> represents the range of business areas in transit. This group develops
> the standards and specifications for data that must be followed
> enterprise-wide.

#### 2.3.1.1 Application-centric and Progression to Data-centric {#application-centric-and-progression-to-data-centric .Style-Heading-4-+-Justified}

Most transit agencies and other organizations are moving away from a
"stovepiped" architecture where most applications were developed
independently for a single business area. This stovepiped architecture
results in a haphazard approach to sharing data and implementing
systems, which is technically referred to as an "application-centric"
approach. This approach can become chaotic and is also referred to as a
"Spaghetti Model of Interfaces" because of its multiple, customized data
connections (see Figure 4).

[]{#__RefHeading___Toc129324146 .anchor}Figure 4 "Spaghetti Model of
Interfaces"

![](media/image12.png){width="3.140277777777778in"
height="2.5597222222222222in"}

When using an application-centric approach, much of the data sharing and
combining occurs through the use of custom data interfaces between
applications. Often, the application wraps a proprietary "skin" around
the internal data produced by the application, making the data
inaccessible to outside queries from off-the-shelf data query tools that
are not provided by the vendor. The inherent complexity and proprietary
nature of these applications make it difficult to find reliable and
current information quickly.

The application-centric approach to data access also makes it difficult
to combine data from different systems into more complex, integrated
reports. To support user needs, IT staff have developed separate ad hoc
reporting tools for each application, which only allows them to view
selected profiles of the internal application data set.

In summary, an application-centric architecture is vulnerable to
problems associated with:

> Separate databases for each application that rely on customer
> interfaces to access data;
>
> Data redundancy, data duplication, or missing data;
>
> Multiple interfaces resulting in high maintenance costs;
>
> Challenging or missing application integration and data sharing;
>
> Lack of business process view for applications and data; and
>
> Difficulty in obtaining data and information for decision making under
> ad hoc circumstances, or when information from multiple systems needs
> to be combined.

In order to successfully meet planned and future ITS application data
requirements, agencies will need an unambiguous transfer of information
between systems and databases, along with assurances that data generated
throughout the agency are consistent, accurate, and complete. For
example, a future Customer Information/Trip Planning system requires
data integrated from multiple sources to operate. These sources include
base map, bus stop, route, and schedule data. Another example of
integrated data is that used for planning. Combining APC data with the
base map, route alignments, and fare information allows planners to more
easily assess ridership. To operate efficiently, these ITS systems must
have the ability to:

> Share spatial information;
>
> Contain updated base maps and attribute information;
>
> Contain updated transit feature data (bus stops and timepoints);
>
> Integrate transit feature data with geo spatial features for analysis;
> and
>
> Transfer real-time data for application transactions.

Many agencies see the benefit of moving from an application-centric
approach toward a "data-centric" or information enterprise approach to
managing applications and data. The reason for this shift lies with the
overlapping data requirements of ITS systems and the potential for data
creation and maintenance efficiencies. As illustrated in Figure 5, the
data-centric approach replaces the application-centric approach to
overcome the disadvantages associated with traditional "stovepipe"
implementations. Placing a database at the center of ITS applications
allows for faster and more accurate business processes, and provides
more meaningful and consistent transit information.

[]{#__RefHeading___Toc129324147 .anchor}Figure 5 Corporate Data
Evolution from Application-Centric to Data-Centric Approach[^16]

![](media/image13.wmf){width="6.4in" height="3.839583333333333in"}

For effective support of transit information needs, enterprise data in
transit needs to have the key technology elements in place, including:

> Core data sets that are shared;
>
> A transportation network;
>
> Commonly shared database management and reporting tools to minimize
> multiple learning curves and maintenance needs;
>
> A distributed logical data model; and
>
> Well communicated policies and procedures.

Despite the advantages, many agencies are having difficulty moving
toward the data-centric approach. Funding to support this type of
relatively hidden data infrastructure is critical. Just as buses and
trains need a good infrastructure to traverse, so does data need a
flexible and robust infrastructure to make information and systems
access quicker, easier, and more accurate. In addition, business
processes must support the elimination of the traditional "stovepiped"
(i.e., departmental focus) systems approach. A critical success factor
is business ownership of the data and supporting applications where
those with the greatest stake in the data's accuracy and currency
guarantee its quality. These business processes must be driven by a set
of agency data policies and standards such as a data dictionary, logical
data model, exchange formats, data owners and custodians, as well as
security and access. Doing so ensures a consistent set of internal data
standards across the organization.

### 2.3.2 State of the Art {#state-of-the-art-1 .Style-Heading-3-+-Justified}

Data development, integration, and management considered to be
state-of-the-art generally include elements such as the use of:

> Agency-wide or regional data dictionaries;
>
> Data standards;
>
> Attention to regional, agency, and project architectures;
>
> Integration strategies;
>
> Publicized and followed policies and procedures;
>
> A standard graphical user interface for accessing the data and
> conducting ad hoc reporting; and
>
> A commitment to funding the development and maintenance of an
> enterprise-wide and/or regional data infrastructure.

#### 2.3.2.1 King County Metro (KCM) Transit Enterprise Database (TED)[^17] {#king-county-metro-kcm-transit-enterprise-database-ted .Style-Heading-4-+-Justified}

In the early 1990s, Seattle Metro Transit, now called King County Metro
(KCM), realized a need to collect core schedule, facilities, and GIS
data for the purpose of creating an integrated, commonly described data
set to be distributed to downstream applications.  This Distribution
Data Base (DDB) became a central authoritative source for integrated
core data sets throughout the agency.  To get started, Seattle Metro
bought the conceptual data model from another agency.  By doing so the
agency was able to populate fields they could use immediately,
and modify or migrate to other fields as needed.  The DDB enabled
significant reporting and analysis capabilities. It also enabled
the development of key applications such as the GIS Tool Box, an
application for planners and others who need to create maps and analyze
scheduling and routing data. 

The data model remained relatively stable and unchanged through the
years until about five years ago when agency staff set out to develop an
enterprise transit data model that more precisely met KCM\'s changing
business processes. The new data model was partitioned by subject area
to improve its scalability, distribute ownership of key sets of data,
and shield one business area model change from impacting another.
 Procedures were put in place to track downstream application interface
needs and upstream application interface changes.  In addition, KCM
expanded coverage of the model to include employees, financial
accounting, and projects.  The new data architecture, known as the
Transit Enterprise Database (TED), is composed of several databases
distributed and linked throughout the organization.

Early in the development process, KCM's staff realized that certain data
policies and procedures were needed to deploy an enterprise data system.
 Some of the more important steps taken by the agency to accomplish this
include:

-   Creation of an enterprise data dictionary with common names,
    conventions, and descriptions adopted across the organization;

-   Assignment of ownership of relevant data to individuals who care the
    most about the accuracy of the data.  For some bus stop data, this
    might be the customer information service representative who deals
    with customer complaints when the service data is incorrect; and

-   Creation of new database access and security tools that allow more
    than one person to update a general category of data. For example,
    types of bus stop signage might be updated by someone in Customer
    Information and the type of shelter at a bus stop might be updated
    by someone in the facilities department.

#### 2.3.2.2 TriMet Enterprise Database {#trimet-enterprise-database .Style-Heading-4-+-Justified}

TriMet, Portland, OR, began with a data model and central data
repository that dates back to the late 1980s. The model evolved from a
single table to the point where the database is now the central
repository where data processing occurs and data is distributed to
downstream applications as needed. According to one Tri-Met manager,
evolving the data model to accommodate new applications is much like
"performing an environmental impact study"[^18] in that each new
application requires integration with the existing database design. When
new applications provide additional data, the model may be changed to
accommodate a one-way feed into the enterprise database to support the
integration processing, storage, and distribution of those data.

TriMet's enterprise data approach enables a wide range of benefits,
including:

-   Sharing data and data maintenance efforts in the region;

-   Easy to maintain access methods of core data by ITS applications,
    such as schedules, routes, and bus stop information;

-   A seamless linking for the user of spatial and nonspatial data;

-   The ability to easily do ad hoc data analyses and mapping; and

-   Allowing both desktop and Web access to data by TriMet employees,
    regional partners, and transit customers. Examples of ITS data that
    are extensively accessed, analyzed, and mapped at TriMet include
    their APC and AVL data.

#### 2.3.2.3 WMATA Interactive Electronic Technical Manuals (IETM)[^19] []{.mark} {#wmata-interactive-electronic-technical-manuals-ietm .Style-Heading-4-+-Justified}

New data approaches are now being included in some state-of-the-art
transit applications to enterprise data. Broadly defined content, such
as documents, technical manuals, other media, and service and
performance information can now be linked together and managed through a
workflow and the data's life cycle. The tool making this possible is
referred to as an interactive electronic technical manual (IETM). WMATA
recently deployed an IETM to integrate their maintenance management
system with related maintenance manuals, integrated parts catalogs,
warranty information, electronic equipment specifications, and other
critical documents.

By integrating additional information technologies using off-the-shelf
standards and tools, the IETM enables WMATA to link related information
and to reuse, revise, distribute, and control informational content in
different forms. The current implementation supports information
pertaining to the agency's heavy rail car rehabilitation content. Future
functionality may expand to all of WMATA's maintenance areas. Figure 6
illustrates the functional architecture of the WMATA IETM.

[]{#__RefHeading___Toc129324148 .anchor}Figure 6 Functional Architecture
of WMATA Interactive Electronic Technical Manuals (IETM)

![](media/image14.jpeg){width="7.677083333333333in"
height="5.208333333333333in"}

Military studies have demonstrated that IETM technology[^20] can:

-   Reduce false alarms, fault isolation times, maintenance time, and
    false removal rates;

-   Increase percentage of successful fault isolation;

-   Promote greater effectiveness of inexperienced technicians;

-   Improve personnel and equipment safety;

-   Reduce turnaround time for reporting and correcting technical manual
    discrepancies; and

-   Reduce technician time spent completing maintenance forms.

By using IETM technology, maintenance personnel can view maintenance
information related to specific vehicle identification numbers. The
electronic nature of the IETMs allows instant updates and corrections,
thereby providing the most accurate and up-to-date information to
mechanics to enhance safety and promote equipment reliability.

#### 2.3.2.4 NJ Transit Data Warehouse {#nj-transit-data-warehouse .Style-Heading-4-+-Justified}

A data warehouse is a specialized database that transforms and loads
data from multiple sources. In the extraction and transformation
process, data are "cleaned" and aggregated into a layer that may be
associated with a specific time period. NJ Transit developed a data
warehouse for APC applications and other onboard electronic subsystem
and engine monitoring functions. During this automated process, the
system performs over 70 quality checks on the data before they are
loaded into the warehouse. The quality check process applies business
rules to approximate missing data, correct errors, and flag problems it
cannot solve. The warehouse now generates several performance trending
reports on bus ridership and stop inventory quality.

### 2.3.3 Emerging Trends {#emerging-trends-1 .Style-Heading-3-+-Justified}

#### 2.3.3.1 Regional Transit Stop Inventory {#regional-transit-stop-inventory .Style-Heading-4-+-Justified}

Many regions developing regional transit coordination centers, such as
the "Transit Hub" in the Gary, Chicago, Milwaukee region, the "Transit
Schedule Data Exchange Architecture" (TSDEA) in downstate New York, and
across Florida, are realizing the value of coordinating the exchange of
consistent schedule and transit network data among transit providers.
Exchange of transit service information supports many multiple agency
coordination activities such as scheduling transfers among modes and
providers, informing riders of public transportation stops, and
providing trip planning services to customers. These regional centers
realize the need to establish regional data standards to support the
unambiguous transfer of service data among transit providers. One of the
most difficult activities encountered by these agencies is matching
stops among the various agencies. When the stops enter the regional
inventory they contain different formats for identifiers, they may be
mapped to different base maps or use different referencing systems, they
vary in attribution, and have other differences. For example, a stop may
appear multiple times using different identifiers, address styles, and
location references. That stop is then submitted by the owning agency
followed by all the other agencies using the stop. The process to
reconcile and clean the data is an enormous undertaking. Several
projects including those involving the Metro DC transit agencies, Center
for Urban Transportation Research (CUTR) representing the state of
Florida, Oregon and Washington DOTs, and the New York State Department
of Transportation (NYSDOT) are now undergoing the development of
regional transit stop inventories, and developing standards and tools to
support their maintenance.

### 2.3.4 Challenges and Lessons Learned {#challenges-and-lessons-learned-1 .Style-Heading-3-+-Justified}

There is no easy solution for developing an enterprise data approach.
The key factor that emerges from the various state-of-the-art
deployments is that there is someone who pursues the migration with
vision and dogged determination. While small enterprise systems may be
developed as individual initiatives within an organization, larger
successes require senior management support and long- term commitment
because the deployment affects change throughout the organization.

Key factors in making an enterprise data system successful over the long
term include:

-   Senior management support and commitment to information management
    as a business strategy;

-   Development of an overall plan and migration approach to creating,
    maintaining, and evolving the enterprise data architecture;

-   Development of key data policies and procedures that are widely
    accepted by major stakeholders and business areas. These policies
    and procedures must be supported at the procurement level. Data
    policies may include:

> New applications to develop a one-way feed into the enterprise
> database (i.e., core data are provided to new applications only from
> an interface from the enterprise database);
>
> Data descriptions and semantics used throughout the organization
> conform to an enterprise data dictionary;
>
> Data development and acquisition;
>
> Data access, security, and ownership rules;
>
> Data policy committee; and
>
> Internal standards for archiving and describing data sets (metadata);

-   Understanding the need to accommodate change into the process
    because technology is evolving at a fast rate;

-   Developing a clear set of requirements and reports that meet
    business needs and challenges before an application is developed.
    Make sure that the information infrastructure can support those
    reporting requirements;

-   Understanding that a trained Database Administrator (DBA) is
    essential to every successful Enterprise Data System. Larger
    organizations may also have a systems analyst and data
    architecture/analyst. The database administrator is needed to
    address the day-to-day operations, while the data analyst supports
    and evolves the data and database structure. The system analyst
    manages and develops programs that require information from the
    database; and

-   Speaking to transit professionals at other organizations who have
    deployed similar applications and learning from their challenges.

## 2.4 Geographic Information Systems (GIS) {#geographic-information-systems-gis .Style-Heading-2-+-Justified}

Spatial data, such as the geographic location of bus stops, routes,
transit facilities, and the regional street network, are critical for
the efficient operation of transit. Transit management needs to know
where their operators, vehicles, facilities, and customers are located
to best plan and operate their systems. GIS provides the tools for
creating, managing, analyzing, and displaying spatial data, and for
supporting ITS applications. Spatial data and some GIS functionality are
also critical for supporting ITS applications such as AVL, APC, and
Itinerary Planning systems, as well as others.

GIS data and applications must become essential elements of an agency's
information technology and ITS architectures to ensure an effective and
efficient information technology infrastructure. Spatial data should be
considered one of the most important subsets of the transit agency's
enterprise data described in section 2.3 above. Many of the best
practices developed for regular data management also pertain to spatial
data. This section will discuss spatial data in additional detail
because of its close links to GIS systems.

Integration of both GIS and spatial data efforts, within a transit
agency or region, can provide some of the biggest integration
cost-saving benefits in ITS. With so many ITS applications in transit
using a street network base map and transit features such as stops and
routes, having only one database in which to maintain a particular data
set is a big benefit in terms of lower costs, more efficient use of
staff time, and better data consistency. Having only one GIS system
saves licensing costs and reduces training requirements. Benefits can
also include more efficient service delivery, better quality services,
more accurate customer information, and improved integration between
modes and service providers.

### 2.4.1 Technology Description {#technology-description-2 .Style-Heading-3-+-Justified}

GIS is not an off-the-shelf application, but a complex information
system comprised of key components. In addition to staff trained in GIS
skills, GIS consists of the following five architectural components:

-   **Data**: A wide range of spatial data can be supported by a GIS,
    such as points, lines, polygons (e.g., zip code area, census blocks,
    fare zones, etc.), and remote sensing data.

**Databases**: A data repository is needed for the spatial data and its
associated features. Database management functions, some specialized to
spatial data, are also needed. A GIS supports the association of
descriptive information about an object with its geographic location.
The GIS also facilitates the combining of different types of geographic
data and map layers, such as waterways, transit routes, streets, and
landmarks. Another important function of the database is to make its
data contents available to users and other information systems.

-   **Software**: GIS software provides the tools to create, update, and
    manage spatial data and associated nonspatial data, such as the bus
    stop amenities associated with a bus stop location. A GIS also
    provides a wide range of spatial analysis and mapping tools.

-   **Applications**: Since GIS is a broadly used tool across many
    industries, industry-specific GIS applications need to be developed.

-   **Hardware**: GIS analyses and spatial data management often require
    a relatively large amount of computing "horsepower." More disk space
    and memory are needed, as are faster network speeds, larger display
    devices, and powerful output devices for mapping displays.

    Linked with the GIS are the following four broad categories of
    spatial data management processes:

-   Data creation or collection, which may involve a variety of methods
    such as map digitizing, geocoding, or GPS-based data collection
    efforts.

-   Maintenance and management of spatial data, including data security
    and possible linkages with an enterprise database management system
    (DBMS).

-   Geoprocessing, such as buffering, geocoding, spatial analysis and
    queries, projections of data, querying for an optimal route between
    and origin and a destination, and generation of distance
    calculations.

-   Data output and distribution to end users, IT and ITS business
    systems, and to external agencies.

### 2.4.2 State of the Art {#state-of-the-art-2 .Style-Heading-3-+-Justified}

A large percentage of transit agencies are using GIS according to TRB's
Transit Cooperative Research Program (TCRP) Synthesis 55 document
published in 2004 and titled "Geographic Information Systems
Applications in Transit." These results are based on the 2003 Transit
GIS Survey,[^21] which is currently being updated. The Synthesis 55
report examines the value of GIS to transit agencies and summarizes the
experiences of a variety of transit agencies with information provided
from a variety of different sized agencies. The Synthesis documents
current practices, effective applications, and includes several case
studies and challenges.

State-of-the-art advances in GIS have occurred in several areas, with
many regional and enterprise-wide GIS systems implemented by transit
agencies. Web-based maps and GIS applications are faster to develop and
faster to use, plus their features and appearances have also improved. A
growing number of agencies are incorporating multiple views of the
spatial data, such as showing the street network in line form, in
remotely sensed images, or with the two combined. In addition, LIDAR
(LIght Detection And Ranging) data, which provides spatial data with
*x*-*y*-*z* coordinates, is starting to be used in a few transit
applications.

A closer linkage is now possible between GIS and database management
systems (DBMS). Some spatial data can now be stored in some commercial
DBMS. As a result, GIS is better able to support ITS applications and
data maintenance efforts. Finally, new GIS-based applications that
support incident tracking or management, such as security incident
tracking systems, can help agencies better understand event patterns
and, as a result, better deploy resources.

TriMet has produced some of the most progressive GIS applications in the
U.S. Some of the important features of the agency's GIS environment
include:

-   A single base map for efficient data maintenance and high data
    accuracy;

-   A commitment to systems integration and linkages to an
    enterprise-wide relational database;

-   A well-designed Configuration Management Plan for Base Map Updates
    in a regional area;

-   A Location Referencing Authority Table[^22] that facilitates
    location referencing and transit GIS tools that can be reused in a
    range of applications; and

-   A GIS working group that is part of the Information Technology team
    helps it to adhere to IT and ITS standards, better share IT
    resources and purchasing power, have an agency-wide business
    perspective, and better integrate GIS with the IT infrastructure.

As a result, TriMet has been able to support a wide range of GIS and ITS
applications such as AVL, APC, Work Order Tracking, Customer Complaints,
Trip Planning, and real-time Transit Tracker. TriMet's interactive
transit Web maps are attractive, helpful, and easy to use. Figure 7
shows the query options for TriMet's interactive Web map. Figure 8 shows
a ridership analysis example, at the bus stop level,[^23] from the
agency's Bus Dispatch System (BDS) Mapper application, which analyzes
historical data gathered by TriMet's AVL and APC systems.

The BDS Mapper application can also display ridership analysis using
varying thickness of line width to show ridership levels between stops,
between time points, and at the route pattern level.

[]{#__RefHeading___Toc129324149 .anchor}Figure 7 Example from TriMet's
Interactive Transit Map

![](media/image15.jpeg){width="6.3125in" height="4.354166666666667in"}

[]{#__RefHeading___Toc129324150 .anchor}Figure 8 Ridership Analysis
Example from TriMet's Bus Dispatch System Mapper

![](media/image16.jpeg){width="7.125in" height="5.34375in"}

The Metropolitan Transportation Commission (MTC) in the San Francisco
Bay area has a regional database that includes spatial data. Having a
regional, enterprise approach to transit GIS allows MTC to facilitate
ITS applications such as regional trip planning as well as other
planning and customer information applications. MTC's regional approach
to GIS also supports integration across transit modes and carriers.

The location of Cape Cod Regional Transit Authority buses is shown on
its Web-based Cape Cod AVL Mapper. The project was implemented by the
GeoGraphics Laboratory at Bridgewater State College in
Massachusetts.[^24]

The prototype system was designed to be affordable by smaller agencies.
The hardware is commercial-off-the-shelf (COTS), while the software is
freeware (e.g., Linux) or resides in the public domain. The system
provides AVL Web-mapping with one-second refresh rates. It also provides
the estimated time of arrival of each vehicle at principal bus stops.
Bus location can be accessed by customers from their desktop computers,
campus kiosks, wireless laptop/PDA at bus stops, or while onboard the
bus.

The Utah Transit Authority has taken an enterprise-wide approach to GIS,
allowing it to have more accurate and efficient GIS applications and
data maintenance efforts.

"Estops," an online GIS-based tool that maintains transit bus stop
inventory data, was developed by the San Diego Association of
Governments (SANDAG) for transit operators in the San Diego region. The
tool, the first of its kind, allows agencies to maintain their own stop
inventory data in a centralized database by using a secured Web site.
Now that GIS and DBMS technology advances are available, SANDAG would
like to upgrade the system to have only one underlying, integrated
database and faster mapping capabilities. The region has benefited for
years from a single regional bus stop inventory that features unique ID
numbers for commonly shared stops, and unified protocols for changing a
stop and notifying other affected agencies.

WMATA has implemented on the Web a very clear and easy to use Metrorail
Street Map[^25] shown in Figure 9 that allows the user to zoom, scroll,
and see station details. The application was implemented using an
application program interface (API), which was made available to
developers of map applications for beta testing.

[]{#__RefHeading___Toc129324151 .anchor}Figure 9 Interactive Metrorail
Map from WMATA

![](media/image17.jpeg){width="6.498611111111111in"
height="3.8777777777777778in"}

King County Metro Transit (KCM) has also taken an enterprise-wide
approach to GIS. This integrated approach has core spatial data for the
region and tools in a GIS Toolbox that are used by a wide variety of ITS
applications. Examples of KCM's state-of-the-art

GIS-based applications include the GIS Toolbox, a Security Tracking
System, and a GIS-based Stop Information System for the creation,
maintenance, and display of bus stop and route stop sequence
information. Figure 10 shows an output from KCM's Stop Information
System.

KCM has also recently implemented TNET (Transportation Network),[^26]
which provides the King County region with a feature-rich, accurate base
map that is maintainable by the various cities and jurisdictions in that
region. Only recently has the technological infrastructure advanced to a
level that allows the introduction of sharing data maintenance of a
centrally stored geodatabase by widely dispersed multiple users.

Participants in the TNET Consortium will realize benefits that include:

-   Reduced data costs;

-   Improved data quality;

-   Minimized data conflicts;

-   Improved participant operations;

-   Leveraged technology investments; and

-   Improved support for cross-jurisdictional decision making.

KCM also conducted an innovative analysis that combined GIS and LIDAR
data (location and altitude data) to determine the best site options for
a radio repeater.

[]{#__RefHeading___Toc129324152 .anchor}Figure 10 Example from KCM's
Stop Information System

![](media/image18.wmf){width="5.981944444444444in"
height="4.790277777777778in"}

### 2.4.3 Emerging Examples {#emerging-examples .Style-Heading-3-+-Justified}

Google, the search-engine company, is currently beta testing a GIS-based
Transit Trip Planner on the Web at
[www.google.com/transit](http://www.google.com/transit), which provides
powerful viewing options of the spatial data and transit data provided
by TriMet in Portland, Oregon.

New tools have allowed a number of other individuals and organizations
to provide alternative spatial layouts of transit schedule and trip
planning data by "data scraping" transit Web sites and displaying the
transit data using new or Open Source Software tools. These efforts pose
some issues for transit agencies because sometimes the alternative
efforts present the data in a more attractive manner than the transit
agency is able to present on its own. However, the "data scraping"
approach is not robust and these supplemental Web sites, which can be
popular with the public, may provide inaccurate data if the transit
agency changes the Web site that is being "scraped."

#### 2.4.3.1 Emerging Spatial Information Standards {#emerging-spatial-information-standards .Style-Heading-4-+-Justified}

There are several spatial data, GIS, ITS, and transit standards emerging
to support integration and interoperability. Examples of these standards
include:

-   Geographic Markup Language (GML), which is a specialization
    eXtensible Markup Language (XML);

-   Transit Communications Interface Profile (TCIP);

-   The U.S. government's Geospatial One-Stop;[^27]

-   Location Referencing Method Specification (LRMS);[^28] and

-   Other ITS standards.

This list of useful standards and tools is expected to grow in the
future and benefit transit. The Open Geospatial Consortium, Inc. (OGC)
is a nonprofit, international, voluntary consensus standards
organization that is leading the development of standards for geospatial
and location-based services.

Listed below are brief excerpts on some of the key emerging
spatial-related standards from the TCIP Concept of Operations.[^29]
Additional information on these standards is included in Section 2.6,
Transit ITS Standards.

-   **TCIP:** TCIP spatial data frames and data elements are used within
    TCIP messages in all TCIP business areas. TCIP references and
    incorporates elements of other spatial standards such as LRMS.
    Although there are many spatial feature transfers that are not
    within the scope of TCIP, there are other related and consistent
    industry standards that can work in conjunction with TCIP to provide
    the interfaces necessary for a transit agency to implement a robust
    spatial data management process.

-   **Geographic Markup Language (GML**): This standard, available from
    the Open Geospatial Consortium (OGC), describes geospatial feature
    relationships and formats that may be used to compose a
    transportation network and/or location references associated with
    spatial features (e.g., bus stops, route segment paths, etc.). It
    contains geospatial descriptions for a variety of layers including
    hydrology, cadastral, and transportation. It is used in a wide
    variety of environments and industries, and includes support by most
    GIS products.

-   **GeoSpatial One Stop (GOS)**: Defines the representation of
    geospatial data, their definition, format, and relationship,
    including feature sets for various geospatial domains including
    hydrology, transportation (roads, rail, air, waterways, and
    transit). GOS describes data type definitions for vehicle and
    operator assignments, trips, routes, transfer points, amenities, and
    more. The model may be used to create an XML Schema using GML or
    TCIP/LRMS.[^30] The GOS program includes the specification of Web
    services for publishing, searching, and viewing geospatial feature
    sets.

-   **Location Referencing Method Specification (LRMS):** The LRMS
    standard describes the data elements and frames necessary to
    describe location references using a variety of geographical,
    addresses, and linear reference methods as it relates to a
    transportation network. Also based on XML, LRMS describes more types
    of linear and attribute (i.e., address) referencing methods for
    transportation than GML, however, the relationship among the spatial
    features are assumed from a given transportation network. LRMS is
    used in TCIP primarily to define data elements and frames that
    provide many of the spatial data concepts that are used throughout
    TCIP and other ITS Standards. LRMS spatial data concepts support a
    variety of representations for geo-spatial data including
    address-based, latitude-longitude, and state plane coordinates.

### 2.4.4 Challenges and Lessons Learned {#challenges-and-lessons-learned-2 .Style-Heading-3-+-Justified}

#### 2.4.4.1 Barriers to Sharing Spatial Data  {#barriers-to-sharing-spatial-data .Style-Heading-4-+-Justified}

A variety of barriers have been identified that limit or prohibit
agencies from fully realizing the benefits of a GIS. Many of these
barriers limit the efficient development, management, integration,
exchange, and use of spatial location information, which compromises the
support of business needs that depend on spatial data. These barriers
can occur both within a transit agency and between organizations in a
region when data sharing or systems integration is required. The
barriers may be due to technical and/or organizational issues. Examples
of these barriers are provided below.

Multiple databases and applications can introduce barriers due to:

-   Inconsistent naming conventions;

-   Different transit data models;

-   Embedded GIS-like functionality with different data representations;

-   Differences in data source quality;

-   Transformations and translations;

-   Poor documentation (metadata); and

-   Use of different location referencing systems.

Insufficient awareness or knowledge of standards, existing tools, and
available utilities.

Weaknesses in systems specifications and the quality of Request for
Proposals (RFPs).

Insufficient definition and execution of operational and data
maintenance responsibilities. This may also include poor maintenance
agreements with commercial map vendors that result in all of transit's
street and route updates being erased when a new release is issued.

A number of these barriers can prevent the unambiguous referencing of
transit feature location attributes. A significant barrier to success is
how the location of spatial data is characterized or referenced. When
locations are not clearly referenced, they cannot be accurately
transformed from one location referencing method to another, potentially
resulting in unsuccessful data sharing, mapping errors, and other
analysis problems.

#### 2.4.4.2 Lessons Learned {#lessons-learned .Style-Heading-4-+-Justified}

The GIS-related lessons learned that are identified in this section
support successful transit decision making and operations by improving
GIS and spatial data usage in analyses, maps, customer information, and
ITS applications. In additional to using good GIS technology practices,
the effective enterprise-wide use of GIS tools and spatial data requires
the successful integration of traditional management practices with good
systems engineering practices. GIS practitioners voiced a strong need
for good management support to achieve an integrated, efficient approach
to GIS and the support of other ITS applications.

Some of the more significant lessons learned and best practices that
were identified are included below. The 2005 Guidebook on Best Practices
for Using Geographic Data in Transit[^31] identifies additional best
practices, and elaborates on them from the perspectives of general
management, GIS practitioners, and ITS project managers.

[]{.mark}

-   A deliberate degree of standardization is required across the
    enterprise to successfully share information. Users must share a
    common vocabulary including data meaning and format. To fully
    realize the benefit, the data must be stored and accessed similarly.

-   Create an enterprise-wide GIS approach, and define standard access
    methods to share transit feature data and other spatial data.
    Centralize the methods as stored procedures or middleware.

-   Adopt a single, enterprise-wide base map to maintain and propagate
    it to different applications for further customization as needed;
    evaluate the options for acquiring a base map that meets transit
    business needs across the agency.

-   Identify and ensure the quality and accessibility of "core transit
    spatial data." Define a corporate transit feature dictionary and
    define an enterprise data model, store and manage the transit
    features centrally, and establish procedures for collecting and
    updating data.

-   Understand data and application dependencies.

-   Use unique ID numbers for core transit features; do not reuse or
    delete ID numbers during the life of a feature inventory.

-   Define an "Addressing Format" for your agency. A number of options
    exist, such as the format used by the U.S. Postal Service or the
    Census Bureau. The most important best practice is to be consistent
    across all applications within an agency.

-   Develop a spatial data maintenance program and synchronize the
    maintenance schedules for the various applications that use spatial
    data from an enterprise-wide perspective.

-   Have metadata, which is data about data, including documentation on
    data quality. In the metadata, document the quality of the spatial
    dataset, the data collection procedures, and the identification and
    access methods. In addition, support application integration using
    an enterprise-wide repository of integration metadata. Develop the
    repository incrementally as each project is developed.

-   Develop a "location reference authority" such as a location table to
    support transit spatial feature portability and the storing of
    transit feature data. Include several key location referencing
    methods in the feature description or in the location table.

-   Consider sharing data development and maintenance efforts with
    regional partners.

-   Use a systems engineering approach in developing and integrating
    applications, and for the definition of stakeholders and their
    requirements.

-   Use standards. If not available from standards organizations,
    develop and communicate internal standards.

-   Understand the intellectual property restrictions on the access and
    use of commercial data or data stored in commercial applications.

-   Ensure sufficient enterprise data resources (e.g., database
    administration staff, data owners, budgeting for updates and
    training).

## 2.5 Communications  {#communications .Style-Heading-2-+-Justified}

In the past, communications may have been implemented as part of the
deployment of an individual application. Today, the communications
environment is seen as a foundation for supporting a wide range of
agency business processes, new transit service opportunities, and new
methods for delivering these services. Communication strategies are now
being planned in ways that do not limit options for future network
components or services, either within the agency or for reaching beyond
into the surrounding community. A solid communications foundation backed
by good strategies is essential for integrating data, systems, and
business processes.

In regions where transit customers might benefit from the exchange of
information among transportation modes and various public sector
stakeholders, state-of-the-art (SOA) transit operators are carefully
coupling agency objectives with external efforts to improve regional
communications and access to information. With agency efforts becoming
more closely aligned with regional efforts, better communication
linkages are also occurring in the areas of public safety and emergency
response.

To support increasing demands for transparent access to data,
state-of-the-art transit agencies manage the development of the
communications environment as a continuous process to keep it aligned
with agency business strategies and requirements, emerging standards,
plans for future growth, and changing technology. Such a managed
strategy is especially important in environments where the funding
available in any given year may be adequate only for partial
implementation, one "building block" at a time.

### 2.5.1 Technology Description {#technology-description-3 .Style-Heading-3-+-Justified}

Communications systems provide data and/or voice communications for
transit planning, maintenance, operations, and incident management, as
well as coordination with transportation providers and public safety
organizations beyond the transit community. These systems support
mobile, onboard, and fixed-end equipment (i.e., equipment housed at an
agency's management center). Communications systems technologies
include:

-   Analog Radio (voice);

-   Analog radio data modems;

-   Digital Radio (voice and data);

-   Dedicated Short-Range Communications (DSRC);

-   Broadband Wireless Networks;

-   Wireless Local Area Networks (W-LAN) (for automated data download/
    upload);

-   Mesh Networks (special case of short-range communications in which
    multiple nodes are dynamically linked to form a self-configuring,
    self-healing wireless network);

-   Text paging (for transmission of data to remote signage, etc.);

-   Satellite Communications (typically for backup communications);

-   Cellular Telephone (for primary or backup communications);

-   Cellular Data Communications (for remote data collection such as
    AVL);

-   Commercial Telecommunications (network backbones);

-   Internet; and

-   Intranet/Extranet.

Transit communications extend well beyond transit-specific installations
and encompass a great many technologies, environments, and applications,
many of which involve ubiquitous telecommunications technologies
typically installed and maintained by others such as the commercial
telephone infrastructure and the Internet.

Transit communications technologies must either be a part of, or
effectively linked with information technology (IT) communication
networks. The use of open (i.e., non-proprietary) IT standards for
networking has become increasingly critical for support of agencies'
growing demands for transparent access to data. SOA agencies carefully
consider the impact of ITS applications on the overall IT communications
infrastructure, with special considerations as to how the agency's
existing internal local-area-networks (LAN), wireless, and other aspects
of its shared communications infrastructure will be linked and managed
to wide-area-network (WAN) capabilities. This is particularly critical
in cases where information will be disseminated to a community that
extends beyond transit.

Secure WAN access is very important. WAN administration and security
management become critical success factors whenever an agency extends
its services to support information flows to and from users outside its
firewalls. WANs utilize Internet protocols that require additional
security features such as firewall upgrades. They also require higher
bandwidths to support increased traffic, perhaps using Virtual Private
Networks (VPN). These enhanced features may be implemented in
partnership with other regional stakeholders for maximum security,
performance, and cost-effectiveness.

IT networks comprise a myriad of complex technologies, many of which are
beyond the scope of this report. However, Figure 11 from WMATA provides
a conceptual diagram showing basic interconnects among the various
networks and computing systems.

[]{#__RefHeading___Toc129324153 .anchor}Figure 11 WMATA Conceptual
Communications Network

![](media/image19.png){width="4.989583333333333in"
height="3.7916666666666665in"}

As shown in this figure, the Extranet communications network[^32] (i.e.,
the T1/ISDN communication "cloud") is positioned to ensure the exchange
of data among public sector agencies, and may become a regional
initiative. Data from transit vehicles would also be communicated to a
transit agency's network. Appendix A of this report provides
transitional, best practice, and emerging IT network strategies relative
to the OSI 7498-1 Network Reference Model.

For the purposes of this report, focus has specifically been placed on
communications technologies that are likely to be deployed by a transit
agency for communication to and from a transit vehicle, or between field
devices and their associated transit management center. These
transit-specific ITS communications applications have been divided into
three major categories:

-   Wide Area Wireless Communications;

-   Short-Range Wireless Communications; and

-   Corridor and Metropolitan Area Communications.

#### 2.5.1.1 Wide Area Communications {#wide-area-communications .Style-Heading-4-+-Justified}

Wide area wireless technologies support data and voice communications
between transit management centers and transit vehicles, support
vehicles, customer information devices, and transit police services. The
most common of these wide area technologies is dedicated voice radio,
followed by cellular voice and data services, and satellite
communications.

Many of the existing voice radio systems were deployed in a centrally
controlled configuration where users transmit a "request to talk" code
over a dedicated network control channel, and are then automatically
assigned to one of a number of other voice radio channels (frequencies)
for the duration of the actual voice transmission. By allocating the
available voice channels among the users who need them most at a given
point in time, this technology, called "trunking," provides better
frequency utilization than configurations that permanently assign
specific frequencies to specific groups of vehicles.

"Trunked" analog radio technologies represented the state-of-the-art for
many years starting in the 1970s and extending through the mid-late
1990s. More recently, however, as digital radio has matured, transit
agencies are replacing their trunked analog technologies with entirely
digital solutions.

Analog voice radio operates by varying the amplitude (i.e., amplitude
modulation, or "AM") or frequency (i.e., frequency modulation, or "FM")
of a radio signal in response to an audio input. Whether that audio
input is silent or loud, the analog signal consumes the same bandwidth
(i.e., the entire channel).

Digital voice radio operates in a different fashion. Digital voice radio
encodes and compresses a voice conversation into a compact electronic
data stream (ones and zeros) that is then transmitted in a series of
tiny bursts, and then reassembled by the receiver. If the audio input is
silent, no data are sent. Because of this, and because digital radio
allows data from more than one conversation to be carried simultaneously
on a single channel, this technology offers far greater frequency
utilization efficiency than the trunked analog systems popular during
the last century. The quality of digital voice communications can vary
depending on many factors such as quality of service control and channel
bandwidth. However, since the digital voice message is transmitted in a
form that is less susceptible to interference and fluctuations in audio
volume, digital radio often also offers greater voice clarity than
analog.

Additionally, digital radio offers the ability to communicate not only
to and from vehicles, but between the transit management center and its
associated passenger information devices in the field as well. Some
passenger information systems now being deployed utilize this technology
exclusively when communicating to displays in the field. When coupled
with a solar cell for electrical power, these easily installed devices
can communicate with the local infrastructure without requiring any
physical wiring in the field.

Digital radio may be the current technology of choice for
agency-owned-and-operated wide area wireless communications. However, it
is not the only solution available. Many smaller agencies, especially
rural agencies with large service areas but few vehicles, have found it
more economical to simply go to their local cellular carrier. A variety
of cellular solutions have been successfully deployed, sometimes coupled
with satellite communications as a backup to fill any gaps in local
cellular coverage. One advantage of such hybrid systems is the ability
to call upon the relatively limitless bandwidth capability of the
commercial provider to support occasional extraordinary data needs, such
as the transmission of live digital video for incident management
without impacting routine fleet management communications. A downside to
cellular solutions sometimes occurs when the commercial system becomes
overloaded and unavailable during a crisis.

#### 2.5.1.2 Short-Range Communications: WiFi, WiMAX, and DSRC/WAVE {#short-range-communications-wifi-wimax-and-dsrcwave .Style-Heading-4-+-Justified}

Off the shelf technologies for short-range wireless communication are
currently being deployed in communities and at transit agencies across
the U.S. The trend over the last few years has been to deploy Wireless
Ethernet or IEEE 802.11 \[hereafter called 802.11\] to download vehicle
condition and event data, and upload configuration files needed by the
vehicle's onboard systems. Recent deployments are also seeing 802.11
serving as the vehicle area network (VAN) onboard the bus, or used in
conjunction with mobile access routers to provide mobile "hot spots" for
riders to access the Internet while in route.

Wireless standards are based on the wireless Ethernet / IEEE 802.11 or
IEEE 802.16 family of standards. Wireless Fidelity (Wi-Fi) uses IEEE
802.11, WiMAX uses IEEE 802.16, while DSRC primarily uses 802.11, but
may use 802.16 to link back to the conventional telecommunications
infrastructure. Each approach is described in the sections below. Table
3, found at the end of this section summarizes the benefits and
challenges of each technology.

Transit agencies are implementing off-the-shelf Wi-Fi to the emerging
standards identified above. Although the differences among the various
technologies are summarized in Table 3 below, this section will only
describe two emerging wireless technologies:

> WiMAX
>
> DSRC/WAVE

##### 2.5.1.2.1 WiMAX {#wimax .Style-Heading-5-+-Justified}

The IEEE 802.16 WiMAX Air Interface Standard is an emerging
specification for fixed broadband wireless access systems employing a
point-to-multipoint (PMP) architecture.

The WiMAX standard for mobile applications is based on IEEE 802.16e,
which is still in the phase where users are offering comments. While a
dedicated frequency has not yet been assigned by the Federal
Communications Commission (FCC), commercial product vendors are anxious
for its release and are already developing applications, base stations,
and terminals. The standard is expected to be finalized mid-2006.

WiMAX is expected to work in the licensed 2.5 GHz and 3.5 GHz, or the
unlicensed 5.8 GHz frequency. The bandwidth is adjustable from between
1.5 to 2.5 MHz to support efficiencies in segmenting channels to serve
different types of platforms and facilitate transmission over longer
ranges.

The City of Seattle[^33] has demonstrated a pre-standard WiMAX
application at 4.9 GHz. At that frequency, the agency estimated that a
base station would need to cover an area of about a mile radius, with 50
to 55 base stations needed to blanket the city for coverage.

Commercial manufacturers are already gearing up for production. Intel
expects that the WiMAX chips will be sold at about \$300 apiece within a
year of the standard's completion. In the early implementation stages,
before costs drop, it is estimated that base stations will cost \$10,000
to \$15,000, with customer premises equipment (CPE) selling for about
\$500.

##### 2.5.1.2.2 WiMAX versus Wi-Fi  {#wimax-versus-wi-fi .Style-Heading-5-+-Justified}

WiMAX and Wi-Fi are different technologies that are not incompatible.
Although they may function together to provide short-range and long-haul
functionality, they require different equipment. Because they operate at
different frequencies, however, they may be used concurrently to enhance
the services offered (e.g., Wi-Fi may patch or augment WiMAX coverage).
Furthermore, WiMAX may also be used to link the Wi-Fi access points
(whether they are standard or mesh) in lieu of a physical backbone
connection. A summary of Wi-Fi and WiMAX technologies is provided in
Table 3.

[]{#__RefHeading___Toc129324323 .anchor}Table 3 Summary of Wi-Fi and
WiMAX Technologies

+--------+----------+-----------------------------+-------------------+
| **Stan | **Fre    | **Benefits**                | **Challenges**    |
| dard** | quency** |                             |                   |
+========+==========+=============================+===================+
| St     |          | Off the shelf 802.11b       | Bridges may not   |
| andard |          | products                    | be covered by     |
| Wi-Fi\ |          |                             | non-licensing     |
| IEEE   |          | Initial investment is cost  | rules             |
| 8      |          | effective for corridor      |                   |
| 02.11b |          | deployments                 | Additional        |
|        |          |                             | questions related |
|        |          | Support range of up to 1    | to                |
|        |          | mile (with improved         | omni-directional  |
|        |          | technology)                 | intersection      |
|        |          |                             | coverage remain   |
|        |          | Radio transfer of 5-10      |                   |
|        |          | Mbps. Practical data        |                   |
|        |          | throughput of about 5 Mbps  |                   |
|        |          | or less                     |                   |
+--------+----------+-----------------------------+-------------------+
| Wi-Fi  |          | Off the shelf 802.11        | Larger subscriber |
| IEEE   |          | products                    | base is needed to |
| 802.11 |          |                             | cover larger      |
| Mesh   |          | Initial investment is cost  | areas             |
| N      |          | effective for small         |                   |
| etwork |          | deployments                 | Shared bandwidth  |
|        |          |                             |                   |
| \[80   |          | Adaptive network path to    | Latency           |
| 2.11a, |          | base station                |                   |
| b, and |          |                             | Proprietary       |
| g\]    |          | Supports range from device  | implementation    |
|        |          | to Access Point of between  |                   |
|        |          | 4 feet to just under a mile | Standardized Mesh |
|        |          |                             | Network isn't     |
|        |          | Channel of about 15 MHz     | available until   |
|        |          |                             | 802.11s (2007)    |
|        |          |                             |                   |
|        |          |                             | Standardized      |
|        |          |                             | Quality of        |
|        |          |                             | Service           |
|        |          |                             | management isn't  |
|        |          |                             | available until   |
|        |          |                             | 802.11e (2006)    |
+--------+----------+-----------------------------+-------------------+
| 8      | 5 GHz    | Higher speed (54 Mbps)      | Proprietary       |
| 02.11a |          |                             | implementation    |
+--------+----------+-----------------------------+-------------------+
| 8      | 2.4 GHz  |                             | Slower Speed (11  |
| 02.11b |          |                             | Mbps)             |
+--------+----------+-----------------------------+-------------------+
| 8      | 2.4 GHz  | Higher speed (54 Mbps)      |                   |
| 02.11g |          |                             |                   |
|        |          | Ability to handle           |                   |
|        |          | interference                |                   |
|        |          |                             |                   |
|        |          | Interoperability with       |                   |
|        |          | 802.11b                     |                   |
+--------+----------+-----------------------------+-------------------+
| WiMAX\ |          | Delay Spread                | Multi-path        |
| IEEE   |          |                             | interference      |
| 8      |          | Line-of-Sight (LOS) not     |                   |
| 02.16e |          | necessary                   | Mobile WiMAX      |
| and    |          |                             | approved as       |
| 802.1  |          | Improved QOS                | standard December |
| 6-2004 |          |                             | 2005; testing     |
|        |          | Flexible channel bandwidth  | standards due in  |
|        |          | (may be between 1.5 and 20  | late 2006         |
|        |          | MHz) for greater            |                   |
|        |          | efficiencies in serving     |                   |
|        |          | different customer needs    |                   |
|        |          | and segmenting into         |                   |
|        |          | multiple channels           |                   |
|        |          |                             |                   |
|        |          | Supports range of greater   |                   |
|        |          | than a mile                 |                   |
|        |          |                             |                   |
|        |          | Flexible channel size       |                   |
+--------+----------+-----------------------------+-------------------+
| 8      | 2.5      | Mobile and fixed            |                   |
| 02.16e | GHz\*    |                             |                   |
|        |          |                             |                   |
| 802.1  | 3.5      |                             |                   |
| 6-2004 | GHz\*    |                             |                   |
|        |          |                             |                   |
|        | 5.8 GHz  |                             |                   |
+--------+----------+-----------------------------+-------------------+
| DSRC   |          | Robust                      | Unknown at this   |
| /WAVE\ |          |                             | time              |
| \[IEEE |          | Fast                        |                   |
| 1609   |          |                             |                   |
| W      |          | Localized transmissions     |                   |
| orking |          | from vehicle--to-vehicle    |                   |
| G      |          | (V-V) and                   |                   |
| roup\] |          | roadside-to-vehicle\        |                   |
|        |          | (R-V) to serve many public  |                   |
|        |          | safety and private          |                   |
|        |          | commercial applications     |                   |
|        |          |                             |                   |
|        |          | Latency minimization        |                   |
|        |          |                             |                   |
|        |          | Authorization               |                   |
|        |          |                             |                   |
|        |          | Prioritization              |                   |
|        |          |                             |                   |
|        |          | Supports                    |                   |
|        |          |                             |                   |
|        |          | Vehicle speed (up to 120    |                   |
|        |          | mph)                        |                   |
|        |          |                             |                   |
|        |          | Communication range (up to  |                   |
|        |          | 1,000 meters for special    |                   |
|        |          | vehicles; nominal is 300    |                   |
|        |          | meters)                     |                   |
|        |          |                             |                   |
|        |          | System latency (\< 50 ms)   |                   |
|        |          |                             |                   |
|        |          | Data rate (default is 6     |                   |
|        |          | Mbps; up to 27 Mbps)        |                   |
|        |          |                             |                   |
|        |          | Single transaction size (up |                   |
|        |          | to 20K bytes)               |                   |
|        |          |                             |                   |
|        |          | 10 MHz channels             |                   |
+--------+----------+-----------------------------+-------------------+
| IEEE   | 1609.1   | WAVE Resource Manager       |                   |
+--------+----------+-----------------------------+-------------------+
| IEEE   | 1609.2   | 5.9 GHz ITS radio service   |                   |
|        |          | security                    |                   |
+--------+----------+-----------------------------+-------------------+
| IEEE   | 1609.3   | WAVE networking services    |                   |
+--------+----------+-----------------------------+-------------------+
| IEEE   | 1609.4   | WAVE multichannel           |                   |
|        |          | operations                  |                   |
+--------+----------+-----------------------------+-------------------+
| IEEE   | 802.11p  | 5.9 GHz wireless LAN medium |                   |
|        |          | access control and physical |                   |
|        |          | layer                       |                   |
|        |          |                             |                   |
|        |          | based on chipset from       |                   |
|        |          | 802.11a                     |                   |
+--------+----------+-----------------------------+-------------------+

\* Requires a license to operate

##### 2.5.1.2.3 DSRC and WAVE {#dsrc-and-wave .Style-Heading-5-+-Justified}

A number of complementary standards are being developed specifically to
support short-range vehicle-to-roadside, roadside-to-vehicle, and
vehicle-to-vehicle communications. Of particular interest are Dedicated
Short-Range Communications (DSRC) and a new family of standards termed
Wireless Access in Vehicular Environments (WAVE).[^34] Both are being
developed by the Institute of Electrical and Electronics Engineers
(IEEE).

The Dedicated Short-Range Communications (DSRC) effort, originally
sponsored by the U.S. DOT and later migrated to the IEEE Standard
Development Organization, is a derivative of the IEEE 802.11 family of
standards. DSRC technology uses industry- standard IEEE 802.11a
components, thereby leveraging a wider market for the base technology.
The 802.11 version will be called 802.11p. Table 4 summarizes the
performance parameters of the technology.

The proposed standards upon which DSRC will be based are expected to be
promulgated by mid-2006 to 2007. Equipment based on the proposed
standard was demonstrated at the 2005 ITS World Congress in San
Francisco, and a consortium of toll operators is currently working on
prototype equipment and demonstration programs. According to the DSRC
Interoperability Consortium, the technology is about five years from
deployment.

[]{#__RefHeading___Toc129324324 .anchor}Table 4 DSRC 5.9 GHz Prototype
Attributes

  --------------------------- -------------------------------------------
  Frequency Range             5.855 - 5.925 MHz

  Data Rate                   6 - 27 Mbps

  Channel Bandwidth           10 MHz

  Power Output                18 dBm

  Transmit Frequency          10 ppm
  Stability                   

  Channel Switch Time         \<= 2 us

  Transmit Spectral Mask      FCC Class C

  Safety Message Protocol     IEEE 1609 WAVE Short Message
  Support                     

  Internet Protocol Support   IPv6

  External Interface          Ethernet (RJ-45)

  Enclosure Size              4.20" x 7.15" x 1.35" (106.7 x 181.6 x 34.3
                              mm)

  Operating and Storage       -10 to +70 deg C
  Temperatures                

  Input Power                 +12 VDC @ \<3.25 Watts
  --------------------------- -------------------------------------------

The DSRC standard was designed to transmit messages in a short period of
time. In doing so, the standard attempts to achieve the following
performance levels:

-   Low latency;

-   Short to medium range;

-   High data rate; and

-   Directional and omnidirectional frequency capability.

Based on the FCC-assigned frequency and bandwidth 5.9 MHz band
(specifically 5.850 to 5.925 MHz), the standard will support:

-   10 channels;

-   Middle channel is a control channel established to listen to
    announcements (for two-way exchange the channel will announce where
    the reply will broadcast);

-   Two public safety channels in upper portion of the frequency band;

-   Lower channels are medium powered channels that are shared among all
    uses (vehicle to vehicle and roadside to vehicle) for commercial
    applications such as map updates and large files;

-   Lowest channel will have the highest availability and lowest delay,
    for emergency situations such as crash avoidance; and

-   Highest channel contains a power level consistent with traffic
    signal priority (TSP) and intersection collision avoidance
    technology applications.

The DSRC Task Group is developing the IEEE 802.11p standard, which
addresses the wireless signal (physical layer) and access control. The
associated network and data layers of the interface protocol will be
addressed by IEEE 1609 (the WAVE family of standards: WAVE Management,
Channel Management, and Resource Manager). Security standards are being
developed under IEEE 1609.2.

A decision point in the development process will be in 2008 when the
federal government is expected to meet with automakers to decide on
whether to go forward and fund a nationwide deployment of the technology
in consumer vehicles and the associated roadside infrastructure.

#### 2.5.1.3 Corridor and Metropolitan Area Communications: Mesh Networks {#corridor-and-metropolitan-area-communications-mesh-networks .Style-Heading-4-+-Justified}

Early metropolitan area networks required installation of a relatively
high number of wireless access points (hot spots) throughout the area to
be served. Mesh networks take this concept to the next level. Each
device in the field itself becomes a relay point for other devices to
connect through. The mobile devices themselves work together to create a
seamless, continuously reconfigurable grid of high-speed network nodes
reaching out as far as their density allows. This is a new technology
that is just now beginning to be deployed in pilot projects nationwide.
Given sufficient device density and an adequate number of ground-based
"hot spots," it offers bandwidth suitable for electronic messaging,
mobile Internet, and even real-time video applications.

Based on the established Wi-Fi standards, a mesh Wi-Fi network is a
special variation on the 802.11 network that can be continuously built
and configured on the fly. In a mesh network, any device outfitted with
a wireless card and special software may operate as a wireless access
point, router, or end user in a network.[^35] The network is adaptive,
finding alternate communications paths in real time when a node goes
down, is out of range, or is overloaded. The network operates smoothly
only when there is a sufficient density of devices that act as nodes,
and communications may "hop" from one node to another until they reach a
wired backbone.

Wi-Fi signals may extend from about 100 feet to nearly a mile depending
on the type of antenna used at the access point (e.g., a high-gain
directional antenna may be used to provide a long but narrow coverage
area, while a less directional antenna installation can be used to
provide a wider but shorter coverage area).

IEEE 802.11s is an emerging standard now under development to improve
interoperability of mesh networks in the mobile environment. The
standard is expected to be approved in 2007. Lacking an accepted
standard, current mesh deployments are based on proprietary solutions.

### 2.5.2 State of the Art {#state-of-the-art-3 .Style-Heading-3-+-Justified}

State-of-the-art ITS communications for transit are currently
distinguished by such features as:

-   Seamless interoperability between multiple dissimilar radio systems
    through intelligent integration on the back end;

-   Portable or mobile backup facilities suitable for rapid deployment
    for event, incident, or emergency management, or in case of failure
    of primary components;

-   Reduction of required radio channels through increased use of
    electronic messaging in lieu of voice communications;

-   Intelligent failover, with ability to switch between cellular and
    satellite if necessary to ensure critical communications;

-   Support for use of separate technologies for voice and data, if
    desired; and

-   Wireless data communications not just between management center and
    vehicles, but between management center and passenger information
    signs as well.

State-of-the-art deployment examples include:

-   New Jersey Transit Corporation (NJ TRANSIT), Newark, NJ

Characteristics include:

> Self contained, pre-positioned mobile command posts suitable for
> routine operations as well as incident, emergency, and event
> management, with support for bus, rail, and police radio, land-line,
> cellular, and satellite voice and data communications.

-   Utah Transit Authority, Salt Lake City, UT

Characteristics include:

> Integration with public safety.

-   Concho Valley Rural Transit District, San Angelo, TX

Characteristics include:

> Rural transit system application;
>
> Cellular/satellite integration;
>
> 16,000 square mile service area; and
>
> 31 vehicles.

-   Los Angeles County Metropolitan Transportation Authority (LACMTA),
    Los Angeles, CA

Characteristics include:

> Digital radio; and
>
> 2,450 vehicles.

### 2.5.3 Emerging Trends {#emerging-trends-2 .Style-Heading-3-+-Justified}

#### 2.5.3.1 Refarming  {#refarming .Style-Heading-4-+-Justified}

Recent rules promulgated by the Federal Communications Commission (FCC)
will reallocate much of the radio frequency spectrum over the next
several years. Among other considerations, this "refarming" of the radio
spectrum will force some agencies into a more modern radio
infrastructure that supports closer channel spacing than had been
previously available on some older radio equipment.

#### 2.5.3.2 Cellular Digital Packet Data (CDPD)  {#cellular-digital-packet-data-cdpd .Style-Heading-4-+-Justified}

CDPD services are being phased out in most parts of the U.S. As a
result, agencies using this technology for mobile data transmission
should already be planning with their cellular providers for migration
to the next generation of mobile data services.

#### 2.5.3.3 APCO P25 {#apco-p25 .Style-Heading-4-+-Justified}

A new standard for public safety digital radio, promulgated by the
Association of Public Safety Communication Officials (APCO), was
successfully implemented in a multivendor interoperability demonstration
back in 1995. Since then, interoperable radio equipment conforming to
the standard, named "P25," has been implemented by a variety of transit
agencies and public safety organizations in over 50 countries worldwide.
The standard is expected to be particularly attractive to operators
seeking interagency interoperability and multivendor interchangeability
of components within a small to mid-sized service area. The standard may
also be applicable to larger statewide and regional operations as well.

#### 2.5.3.4 Others {#others .Style-Heading-4-+-Justified}

Another innovative approach to wide area communications, originally
developed to improve frequency utilization and reduce communications
costs for medium-sized operators in Europe, is beginning to surface in
the U.S. The Port Authority of New York and New Jersey, in conjunction
with NJ TRANSIT, is conducting a pilot test of an AVL system that does
not involve polling. The system promises reliable arrival time
prediction accurate to within less than one minute. The pilot project,
which is expected to be complete by the end of 2006, will evaluate
reliability of communications, accuracy of arrival time prediction,
timeliness of passenger information, system scalability, capital and
maintenance costs, and opportunities for system integration. Key
characteristics of the technology include:

-   Single data channel;

-   Intelligent mobile subsystem;

-   Exception-based location reporting;

-   Variable reporting frequency based on distance from next stop where
    expected bus arrival time must be delivered;

-   One base station for every 200 vehicles;

-   Vehicles dynamically manage output power to minimum required for
    reliable communications;

-   Primary operator communications is via mobile data terminal

-   Separate radio for voice communications; and

-   30% fewer voice channels required as compared to voice only

#### 2.5.3.5 Wireless Internet  {#wireless-internet .Style-Heading-4-+-Justified}

Several transit agencies are conducting demonstrations of wireless
Internet access for passengers onboard buses. For example:

-   King County Metro is demonstrating and testing wireless Internet
    access on 30 buses. Commercial cell phone carrier infrastructure is
    being used to communicate data to/from the bus WiFi "hot spot"
    (i.e., wireless access point for connecting to the Internet).

-   Community Transit, based in Snohomish County, WA, implemented a
    pilot program in fall 2005 to provide wireless Internet access using
    cell phone carrier infrastructure on some of its longer commuter
    routes.

-   ABQ RIDE in Albuquerque, NM is providing wireless Internet access on
    its 15- mile-long Bus Rapid Transit (BRT) route called Rapid Ride.
    The wireless system has mobile access routers on 12 buses. The
    routers receive the wireless signal from line-of-sight repeater
    antennas mounted on traffic signal cross-members, and then transmit
    the signal to the bus. The system is currently supported by a T-1
    line[^36] and approximately 83 repeater antennas along the transit
    corridor that are approximately ½ to 1½ miles apart. Because it is a
    line-of-sight system, a change in elevation or route direction may
    require an additional repeater antenna to continue the propagation
    of the signal. The system allows for an Internet "hot spot" on the
    vehicle, but not along the roadside. ABQ RIDE is exploring the
    possibility of sending security video data from the bus over the
    wireless connection under certain circumstances. The use of a T-1
    line allows the data transmission to be segmented with a Virtual
    Private Network into multiple purposes with different levels of
    access and security. The system was selected in part because it has
    relatively low ongoing operating costs.

-   The Brockton Area Transit (BAT) Authority on Cape Cod, MA, is
    prototyping a proof-of-concept demonstration of an *e-transit
    village* at Bridgewater State College, which includes using a
    wireless local area network infrastructure (WLAN) based on IEEE
    802.11b for both Internet and fleet management (vehicle location)
    communications. The project team is working on how to better
    maintain a connection when moving between WiFi locations.

-   The Cedar Rapids, IA, transit department, known as "Five Seasons
    Parking and Transportation" (FSTP), began implementing mobile
    broadband wireless on a key portion of their transit routes in
    September 2005. The system uses mobile mesh technology that is high
    speed, self-forming, and self-healing. The system allows wireless
    connection to the Internet and the city's data network. One of the
    goals of the project was to increase the safety of riders and
    transit employees by implementing video surveillance cameras that
    can be integrated with the transit vehicle's global positioning
    system (GPS). As a result, the video can be remotely monitored with
    vehicle location information available to the viewer. Additional
    benefits include the availability of wireless Internet access for
    passengers and the capability to send streaming video to the vehicle
    along with schedule information, rider alerts, and advertising.[^37]

#### 2.5.3.6 IEEE 802.11-based Transit Signal Priority; Wireless Networks in Lieu of Inground Communications Infrastructure {#ieee-802.11-based-transit-signal-priority-wireless-networks-in-lieu-of-inground-communications-infrastructure .Style-Heading-4-+-Justified}

Using off the shelf products, the Los Angeles County METRO[^38]
demonstrated a traffic signal priority (TSP) implementation with the use
of a continuous, end-to-end Wi-Fi network consisting of multiple Wi-Fi
bridges. This wireless TSP implementation was deployed over 40
intersections along 3 jurisdictions (connecting to 3 different traffic
signal control systems). It was based on the IEEE 802.11b protocol. The
bridging technology provided coverage up to three quarters of a mile
through the use of directional antennae mounted on a pole or mast arm.

Some of METRO's key performance issues include:

-   Typical bus travel speeds were from 15 to 35 mph. The system was
    observed to work at speeds up to 40-45 mph;

-   Power fluctuations were a problem until power conditioning devices
    were deployed;

-   Terminal network devices were required to connect controllers to
    Wi-Fi network;

-   Only a one-way transmission was implemented (e.g., bus only sends
    information to controller);

-   The access points/bridges were connected through the existing
    network twisted pair;

-   The approximate cost for each intersection was \$12,000, with the
    onboard portion costing approximately an equivalent sum on a per bus
    basis;

-   Limited bandwidth was needed due to small size of message (uses
    minimal bandwidth); and

-   Directional antennae were used for bridging, which focused coverage
    on narrow road network alignment; the coverage was not tested on
    intersections with intersecting bus priority traffic.

#### 2.5.3.7 Data Transmission over Conventional Analog Radio {#data-transmission-over-conventional-analog-radio .Style-Heading-4-+-Justified}

Data Modem (**Mo**dulate/**dem**odulate) technology allowing electronic
data messages to be transmitted via conventional analog radio was
introduced over 40 years ago, and has been included in many of the
larger transit radio installations ever since. In a new twist on an old
technology, a low-cost solution for wireless data communications between
a transit vehicle, the transit management center, and bus stop signs was
prototyped and tested in a California effort known as the EDAPTS
(efficient deployment of advanced public transportation systems)
project. The California Department of Transportation teamed with the
City of San Luis Obispo (SLO) Transit and California Polytechnic State
University to implement the EDAPTS research project at SLO Transit. One
of the goals of the project was to make ITS more affordable for smaller
transit agencies. One aspect of the project was to "piggyback" the
digital data on the standard analog voice radio system using low cost,
commercially available parts and modules. This approach may represent an
attractive near-term option for smaller transit operators with
significant unused channel capacity on an existing radio system.

In the EDAPTS project, a data modem was added to the analog radio
channel. When the bus left a stop it transmitted a "leaving the stop"
message to the central communications center. The center then used a
text pager to send a text message about the bus' expected arrival time
to solar powered "Smart Transit Signs" located at the next bus stop.
Issues associated with the project included latency in the pager
technology and the need to disable the data modem's retransmit feature
to preserve voice communications capacity required for transit
operations. The next phase of the project will develop performance
specifications and explore commercial options.[^39]

#### 2.5.3.8 Public Access Wireless Infrastructures  {#public-access-wireless-infrastructures .Style-Heading-4-+-Justified}

The movement toward wireless technologies will gain even more momentum
with the emergence of mobile Wi-Fi, mesh Wi-Fi (mesh-network), WiMAX,
and Dedicated Short-Range Communications (DSRC), which are all expected
to mature over the next two to five years. Each is expected to bring
wireless and wide band capabilities to the mobile environment where
challenges such as how to maintain connections in a vehicle moving
through wireless coverage zones are just now being overcome.

These wireless approaches are of particular interest because
municipalities and transit agencies across the U.S. are studying whether
or not to build public access wireless infrastructures and the specific
type of infrastructure if one is built. Many government agencies already
own some amount of fiber optic infrastructure, so wireless access points
could provide last-mile and hot spot coverage to users. This type of
infrastructure can provide economic benefits to the community and may
additionally reduce communications costs for public safety functions
such as police, fire, and transit.

### 2.5.4 Challenges and Lessons Learned {#challenges-and-lessons-learned-3 .Style-Heading-3-+-Justified}

#### 2.5.4.1 Interoperable Communications for Emergency Management  {#interoperable-communications-for-emergency-management .Style-Heading-4-+-Justified}

A number of recent disasters, both natural and man made, have
illustrated the need for transit communications, and especially transit
police communications, to be able to interoperate with those of public
safety and other regional agencies. Such regional interoperability does
not necessarily imply a need for consistency of equipment or technology,
but it does mandate at minimum having the capability to link various
dissimilar communications systems and management centers (back end
operations) with one another.

#### 2.5.4.2 Sub-Optimization of Design Constraints {#sub-optimization-of-design-constraints .Style-Heading-4-+-Justified}

Design constraints limit vendor flexibility in meeting the core needs of
the agency, and may end up costing far more than they are worth. Common
design constraints with respect to communications include:

-   Limitations on the number or placement of radio antenna sites, which
    may unnecessarily impact performance;

-   Specification of a particular communications technology, which may
    unnecessarily impact cost, performance, and supportability; and

-   Requirements for a new fleet management system to make use of an
    existing radio system, which may also unnecessarily impact cost,
    performance, and supportability.

Agencies report that there are significant advantages to be gained
through resisting the urge to sub-optimize design constraints to satisfy
special interests within the organization. One mechanism found to be
especially useful is to require a business case for any design
constraints proposed for inclusion in the system specification. In this
way the constraint can be more easily dropped if it turns out that
satisfying it would cost more than it is worth.

#### 2.5.4.3 Public Access Wireless Infrastructures  {#public-access-wireless-infrastructures-1 .Style-Heading-4-+-Justified}

Several transit agencies have begun planning for the installation of
wireless Internet access onboard vehicles. At the same time, some
municipalities across the U.S. have already begun (or have completed)
deployment of their own public access wireless infrastructures, while
others have secured commitments from commercial wireless service
providers for inexpensive wireless access for municipal services. In
this rapidly changing environment, transit agencies considering wireless
Internet installations are urged to work with municipalities to make
themselves aware of market trends in their respective service areas so
that they might take advantage of cooperative funding opportunities and
avoid undertaking duplicative deployments that will be rendered surplus
or obsolete almost as soon as their implementations are complete.

One potentially advantageous implementation strategy, which is just now
emerging, is for transit agencies to install their own wireless Internet
infrastructure only in those locations where it appears that there may
be an insufficient market to support commercial implementation (e.g.,
along the rural legs of some intercity and commuter corridors, while
working with individual municipalities to leverage local funding and
commercial interests for installation in populated areas).

In some cases, the choice to deploy --- or not to deploy --- public
access wireless infrastructures is being made by state legislatures. Out
of respect for commercial providers, several of the legislatures have
banned the deployment of these technologies by public agencies if they
compete with the private sector. For example, Illinois recently enacted
this type of law. However, many other towns and cities are still
beginning to build fiber and wireless infrastructures to support public
services,[^40] either as truly public infrastructures or via compromise
agreements for low-cost services through their local commercial
providers. Thus, it is also important for agencies to be aware of their
legislative environment when planning their wireless strategy. In all
cases, proactive outreach to individual municipalities appears to be an
important key to success.

#### 2.5.4.4 Shifting Technology Needs  {#shifting-technology-needs .Style-Heading-4-+-Justified}

Some transit agencies are considering whether the use of cell phones and
access to information via cell phones and personal digital assistants
(PDAs) will be so common in our society that some transit communications
projects may not be needed, or the benefit-to-cost ratio will be poor.
For example, some transit ITS projects to install communications and
electronic information at bus stops take many years to plan, budget, and
implement. In addition to the implementation budget costs, ongoing
operations and maintenance costs are added to the agency's operating
budget. It is possible that if the project takes too long to implement
it may not be needed, especially if personal access to data is
widespread at the time of implementation.

#### 2.5.4.5 User Support  {#user-support .Style-Heading-4-+-Justified}

Providing public wireless Internet access on a transit vehicle may place
unexpected demands on the vehicle operator. Passengers need to be taught
that bus operators and train crews are not equipped to answer questions
or provide assistance with wireless access problems.

#### 2.5.4.6 Evolving Technologies {#evolving-technologies .Style-Heading-4-+-Justified}

##### 2.5.4.6.1 "Just in Time" Technology Procurement  {#just-in-time-technology-procurement .Style-Heading-5-+-Justified}

Information technology evolves at a far faster rate than do vehicles or
facilities. Sometimes, information technology specified at the front end
of a project will be two generations behind the times and no longer
supported by the vendor community by the time the project is built.
Performance requirements, test plans, and acceptance criteria can and
should be specified up front, but procurement of the actual technology
for delivering on those requirements should be delayed until just prior
to actual installation. Moreover, it should be recognized that while
emerging standards can offer real value, they are just that, "emerging"
and subject to change. The issue of early migration to "emerging"
communication standards and practices, such as in IP telephony, mesh
networks, standard interface profiles, and other areas of convergence,
should be examined carefully with a clear focus on risk management.

##### 2.5.4.6.2 Communications Infrastructure Supportability and Administration  {#communications-infrastructure-supportability-and-administration .Style-Heading-5-+-Justified}

To insure a cost-effective, reliable, and secure communications
infrastructure, it is important that ITS communications be planned for
integration of network management with the rest of the agency's IT
communications infrastructure. Other supportability issues may include
the need for new troubleshooting and maintenance skills, and possibly
shorter equipment life cycles because some of the components in data
radio systems are more like traditional IT equipment than the
long-lived, more rugged radio equipment of the past.

## 2.6 Transit ITS Standards {#transit-its-standards .Style-Heading-2-+-Justified}

A standard or protocol is defined as a set of rules or measures with
which to compare or build similar objects. In 1995, the U.S. DOT
initiated a standards program to accelerate the transportation
industry's development, adoption, and deployment of technology standards
for ITS. The transit industry started addressing these concerns back in
March 1992[^41] with the initiation of the ITS-America Advanced Public
Transportation System (APTS) Bus/Vehicle Area Network (VAN) Working
Group. Since that time, many other initiatives have been started by
Standard Development Organizations (SDOs) to develop standards and best
practices guidance for transit ITS systems in the U.S.[^42]

The USDOT initiated the standards effort as a way of decreasing the time
it takes to deploy technology and reducing ITS life cycle costs. In
general, the adoption of standards has lowered costs and reduced the
complexity of installing and operating electronic- and computer-driven
systems. The FTA Policy on ITS National Architecture and Standards
emphasizes that projects consider using industry standards for transit
ITS deployments to benefit from lowered costs over the system life and
to facilitate integration and interoperability. The ITS standards are
conceptually mapped to the National ITS Architecture to support a
traceable, end-to-end requirements process from planning to operations
and maintenance.

### 2.6.1 Standard Descriptions {#standard-descriptions .Style-Heading-3-+-Justified}

Standards may be classified in many different ways. The primary set of
standard types needed by ITS applications fall into three major
categories:

-   Interface and information standards;

-   Communications technologies and standards; and

-   Device technologies and standards.

This section only deals with "interface standards." Details on
communications protocols are discussed in Section 2.5, Communications.
Device standards are briefly discussed in the relevant sections of the
document or are outside the scope of this report. On the other hand,
interface and information standards enable multiple systems to interact
and share needed data. Generally, interface and information standards
describe the semantics, formats, encoding, and behavior of information
that is exchanged among multiple systems. There are typically many
different information standards that must work together to ensure
end-to-end interoperability. The information technology industry
describes many standards to meet most application exchange and service
functionality. These standard classifications are listed below in Table
5:

[]{#__RefHeading___Toc129324325 .anchor}Table 5 Standard Types and
Descriptions

  -----------------------------------------------------------------------
  **Standard Type**        **Description**
  ------------------------ ----------------------------------------------
  Business Semantics       Standards that describe user-driven
                           requirements for target domain services and
                           information

  Orchestration / Dialog   Standards that provide templates and enforce
                           requirements for exchanging messages and
                           managing services

  Security                 Standards related to securing services and
                           information

  Discovery                Standards that enable a system to discover and
                           understand features of a service, dialog, or
                           message

  Description / Metadata   Standards that describe the requirements
                           deployed in a service, dialog, or message

  Message Processing       Standards that describe the requirements for
                           describing a message

  Data Extraction          Standards for extracting information from a
                           service or message

  Data Semantics           Standards that enable a user to describe the
                           meaning of information

  Data Syntax              Standards that describe the format of
                           information/data

  Transformation and       Standards that describe how to efficiently
  Encoding                 change, encode, or decode the format of data

  Transport                Standards that describe how to transmit
                           information from one system to another
  -----------------------------------------------------------------------

Many of these information standards rely on other standards to work
effectively. For example, many mature and emerging standards are based
on the World Wide Web Consortium (W3C) Extensible Markup Language (XML)
and XML Schema standards. A standard that supports the description of
another standard is called a "base standard." For example, the base
standard used to describe the Transit Communications Interface Profiles
(TCIP) messages is a business semantics standard called the World Wide
Web Consortium XML Schema. A standard or group of standards that
describe rules for how to apply a base standard(s) in order to ensure a
high degree of interoperability is called a "profile." The framework for
deploying information technology today depends on this IT standard
classification and group of standards which together ensure
compatibility among commercial off the shelf applications and tools.

Transit standards more closely tied to device and critical systems may
use other sets of standards, for example, onboard vehicle systems for
bus uses the SAE J1708 family, and rail uses the IEEE Rail Transit
Vehicle Interface Standards (RTVIS).[^43]

Among the standard development areas to be discussed in this section
are:

-   Integrated Fare Management Standards

> APTA Universal Transit Farecard Standards
>
> APTA Transit Communications Interface Profiles Fare Collection
> Business Area
>
> ISO/CEN Integrated Fare Management Standard
>
> INCITS Transit Fare Cards --- Interoperability Framework for
> Contactless Fare Payment Technologies and Systems

-   APTA Transit Communications Interface Profile (TCIP) Standard

-   SAE Vehicle Area Network (J1708 Family of Standards)

-   ISO

> European Union Transmodel
>
> Bus Numbering System
>
> PRESTO

-   ITS Related Standards

> NTCIP 1211
>
> NTCIP 2306
>
> SAE ATIS/LRMS

-   GeoSpatial One Stop

#### 2.6.1.1 Integrated Fare Management Standards {#integrated-fare-management-standards .Style-Heading-4-+-Justified}

A characteristic of standards for fare collection is that there are many
options and few comprehensive solutions at the time of this report.
Existing and emerging fare collection standards address requirements for
different levels within the overall fare management system architecture,
from the front-end device level for performing card issuance, reading,
and writing functions to the clearinghouse level functions. These
functions and fare architecture levels are described in more detail in
Chapter 4, Electronic Fare Payment. The functionality and interfaces
between these architecture layers are associated with different,
sometimes divergent standards.

##### 2.6.1.1.1 U.S. Fare Card Standard Efforts {#u.s.-fare-card-standard-efforts .Style-Heading-5-+-Justified}

There are two U.S. efforts to generate standards for the electronic fare
management system. The APTA Universal Farecard Standards effort (UTFS),
initiated its work in 2001, and the APTA Transit Communication Interface
Profiles (TCIP) began the fare collection section in 2004. In addition,
there are international standards governing form, fit, and factor
standards for media (e.g., card) standards.

##### 2.6.1.1.1a Media Standards {#a-media-standards .Style-Heading-5-+-Justified}

The most popular card standards that are specified in the U.S. and
Europe are ISO 7816 and ISO 14443 Type A and B. ISO 7816 is a contact
card standard. The contactless integrated circuit card, ISO 14443,
supports version Types A and B. The main differences between the two
types consist of modulation methods, coding schemes, and protocol
initialization methods. At this level, neither of these ISO standards
addresses application issues for fare payment, such as card/media data
layout, application commands, security, and other related aspects.

##### 2.6.1.1.1b APTA Universal Transit Farecard Standards  {#b-apta-universal-transit-farecard-standards .Style-Heading-5-+-Justified}

The Universal Transit Farecard Standards (UTFS) effort is composed of
three committees (Fare Media Committee, Operations Committee and
Financial Management Committee) that address the various institutional
and technical interoperability issues that arise with deploying
integrated fare management systems.[^44]

The Fare Media Committee was established to provide standards,
guidelines, and best practices on magnetic fare media to the public
transportation community. The committee deliverables are:

-   Trends in Electronic Fare Media --- Completed and published

-   Farecard Procurement Guidelines and Specification for Magnetic
    Striped Instrument Design --- Completed and awaiting ballot to be
    published

The Operations Committee was established to identify the critical
elements essential to the implementation of an Automatic Fare Collection
(AFC) System. In addition, the committee developed guidelines and
recommended practices for transit agencies to use in planning,
designing, procuring, implementing, and maintaining a local and/or
regional AFC System. The committee deliverable is:

> AFC Planning and Implementation Guidelines --- Completed and awaiting
> ballot to be published

The Special Industry Liaisons were identified to coordinate UTFS efforts
with the I-95 Corridor Coalition to identify any interoperability issues
and also with the Smart Card Alliance to obtain input from the financial
industry.

The Financial Management Committee develops standards and guidelines
related to all aspects of financial reporting, clearing, and settlement.
Under the UTFS Financial Management Committee, two working groups, the
Business Process Work Group and the Systems Work Group, were established
to address the business and technical issues.

The two working groups have been prolific in planning and developing
specifications, guidelines, and preliminary standard documents to
address key interfaces between fare collection subsystems. These
interfaces were assigned to four work packages (of which three are
active):

> Work Package 1 (WP1): Card: Developing guidelines and standards
> related to smartcards.
>
> Work Package 2 (WP2): Card Reader: This work package has been
> eliminated.
>
> Work Package 3: Security: Addressing only the critical areas of
> concern for the security planning associated with the smart card-based
> components of AFC systems. (This work has been completed and
> published.)
>
> Work Package 4 (WP4): Back Office: Producing standards and guidelines
> to enable the interoperability between a single transit system's fare
> payment devices and a central computer system and interoperability
> between two (2) regional central computer systems.

Initially, the objective of the effort of UTFS Work Package 4 was to
achieve interoperability at the component level, enabling vendor
components to work within the same architecture level. This ambitious
goal was revised to at this time to achieve subsystem interoperability,
"in which a subsystem is defined as a 'black box' encompassing the
Automatic Fare Collection (AFC) equipment, local computer, and central
server."[^45] Specifically, the subsystem that is most affected is the
back-end where now only a messaging standard between the agency central
computer system[^46] and the local depot system[^47] will be developed.
This effort will be referred to as WP4+ as depicted in Figure 12. The
standard that links the agency central computer[^48] with the regional
clearinghouse[^49] referred to as WP4 is generally unaffected by the
addition of WP4+.

[]{#__RefHeading___Toc129324154 .anchor}Figure 12 UTFS Work Package (WP)
Scope

![](media/image20.jpeg){width="6.498611111111111in"
height="3.865972222222222in"}

##### 2.6.1.1.2 Transit Communications Interface Profiles: WG 7 Fare Collection {#transit-communications-interface-profiles-wg-7-fare-collection .Style-Heading-5-+-Justified}

Although its scope is broader than fare collection, TCIP only addresses
the data descriptions and message exchange requirements for a single
agency's bus fare collection system configuration and maintenance
processes.[^50]

**Comparison of UTFS and TCIP Scopes (From "APTA RMC Agenda 20050321 -
UTFS TCIP Coordination")**

  ------------------------------------------------------------------------
                           **UTFS**                 **TCIP**
  ------------------------ ------------------------ ----------------------
  Regional/Single          Regional System          Single Agency

  Mode                     Multimodal               Bus Only

  Fare Media               Smartcards (Magnetic     All Fare Media
                           cards under              
                           consideration)           

  Security                 Security Guidelines      Not in scope

  Clearinghouse and        Clearing House and       No CH/RSC Function
  Regional Service Center  Regional Service Center  
  (CH/RSC)                 Function                 

  System Configuration     Not included             Only for fare box
                                                    onboard bus

  System Maintenance       Not included             Only for fare box
                                                    onboard bus
  ------------------------------------------------------------------------

The fare collection exchange requirements include interfaces for:

+-----------------------------------+-----------------------------------+
| > Command Disable Fare Equipment  | > Report Cashbox Reconciliation   |
| >                                 | >                                 |
| > Command Enable Fare Equipment   | > Report Vault Event              |
| >                                 | >                                 |
| > Load Fare Collection Data       | > Subscribe Fare Collection       |
| >                                 | > Health                          |
| > Unload Fare Collection Data     | >                                 |
| >                                 | > Subscribe Fare Passenger Data   |
| > Report Cashbox Event            | >                                 |
| >                                 | > Subscribe Daily Revenue Data    |
| > Report Farebox Validation Error | >                                 |
| >                                 | > Subscribe Fare Equipment Subset |
| > Push Fare Data                  | > Definitions                     |
| >                                 | >                                 |
| > Push Fare Zones                 | > Subscribe Fare Zones            |
+-----------------------------------+-----------------------------------+

These farebox data sets may be uploaded and downloaded via short-range
wireless or radio link as appropriate. (See Section 2.4.3.1 for more
information on TCIP.)

##### 2.6.1.1.3 International Efforts {#international-efforts .Style-Heading-5-+-Justified}

There are numerous international standard development activities and
standards that are emerging or deployed throughout the world. The
European community supports several standards, and Japan and Korea also
have nationwide standards. Many of these efforts cover card and device
level interactions. Some may cover the local depot to central computer
system levels as well. Few cover the central computer system level to
the regional clearinghouse levels.

Until recently, there was little coordination among public transit
operations throughout the world. However, recently the European Union's
standards organization, CEN, brought the Integrated Fare Management
System (IFMS) standard to the international community through the
International Standards Organization (ISO) Technical Committee on ITS,
Working Group 8 on Public Transport and Emergency. IFMS constructs a
framework to describe the functionality, actors' roles and
responsibilities, and alternative operational scenarios that define a
comprehensive fare management system, encompassing the five levels
described in the Electronic Fare Payment Architecture (as depicted in
Figure 2-9), as well as extending those layers to merchant services.

##### 2.6.1.1.4 INCITS Transit Fare Cards --- Interoperability Framework for Contactless Fare Payment Technologies and Systems {#incits-transit-fare-cards-interoperability-framework-for-contactless-fare-payment-technologies-and-systems .Style-Heading-5-+-Justified}

The INCITS Transit Fare Card standard is being developed on a fast track
as of the writing of this section. The standard is based on a
specification and prototype spearheaded by the Port Authority of New
York and New Jersey (PANYNJ) called the Regional Interoperability
Standard (RIS). The RIS standard is also the basis for the UTFS Work
Plan #1 and #4 programs.

#### 2.6.1.2 Transit Communications Interface Profile (TCIP) Versions 2.x and 3.0 {#transit-communications-interface-profile-tcip-versions-2.x-and-3.0 .Style-Heading-4-+-Justified}

TCIP 2.x and 3.0 are APTA-led standards development efforts to develop a
data interface standard that covers the following nine transit ITS
business areas:

+-----------------------------------+-----------------------------------+
| 6.  Common Public Transportation  | 11. Passenger Information (PI)    |
|     (CPT)                         |                                   |
|                                   | 12. Scheduling and Runcutting     |
| 7.  Control Center (CC)           |     (SCH)                         |
|                                   |                                   |
| 8.  Fare Collection (FC)          | 13. Spatial Representation (SP)   |
|                                   |                                   |
| 9.  Incident Management (IM)      | 14. Transit Signal Priority (TSP) |
|                                   |                                   |
| 10. On board (OB)                 |                                   |
+-----------------------------------+-----------------------------------+

The standard is composed of messages and dialogs. Messages are used to
exchange information between applications and dialogs describe the
behavior of message exchange between the exchanging entities. For
example, in the dialog "Subscribe Operator Sign On," a subsystem or
process may send a request subscription message to the component that is
responsible for the operator sign-on function. The responsible agent (or
function) accepts and registers, or rejects the subscription. When
operator sign-on information is available, the responsible agent then
sends the logon information to all registered subscribers. The order of
message exchange, messages, and their constituent data elements and
groups of data elements (data frames) are described by the standard.

In developing these business semantics, TCIP must also describe the
message transfer behavior between processes. These requirements are
described in a series of Concept of Operations detailed in these eleven
sections:

+-----------------------------------+-----------------------------------+
| General Concepts                  | Personnel and Work Assignment     |
|                                   | Management Process                |
| Security and Incident Mana gement |                                   |
| Process                           | Customer Information Process      |
|                                   |                                   |
| PTV Operations Process            | Data Repository Operations        |
|                                   | Process                           |
| Revenue and Fare Collection       |                                   |
| Process                           | Spatial Data Management Process   |
|                                   |                                   |
| Scheduling Process                | Transit Signal Priority (TSP)     |
|                                   | Process                           |
| Asset Management Process          |                                   |
+-----------------------------------+-----------------------------------+

The standard uses Abstract Syntax Notation One (ASN.1) as its data
description language, and the W3C --- E**x**tensible **M**arkup
**L**anguage (XML) and XML Schema standards as one of the preferred
methods of data encoding conformance. The standard allows other encoding
methods provided that they are defined by the systems exchanging
information. No specific application protocol is recommended for
transporting the message.

Conformance to the standard is based on the user (e.g., an operating
agency) defining the Profile Requirements List (PRL), and the equipment
or application developer describing the product operations in a Profile
Implementation Conformance Specification (PICS) for each dialog that is
implemented. Conformance is tested on an interface basis, not an
application or system level. APTA plans to ballot the proposed standard
in early 2006.

#### 2.6.1.3 Bus Vehicle Area Network (SAE 1708 family of standards) {#bus-vehicle-area-network-sae-1708-family-of-standards .Style-Heading-4-+-Justified}

The Society of Automotive Engineers (SAE) family of standards for
heavy-duty vehicles includes standards for application software, serial
communications protocols, hardware and environmental conditions, and
connector and cabling. Table 6 describes the basic application of each
standard, with the appropriate standard listed at the bottom of the
table. Older systems use the SAE J1708 standard, which supports low
speeds (i.e., 1,200 to 9,600 baud) versus SAE J1939 which supports much
higher baud rates (i.e., 4,800, 9,600 and 19,200 baud) used for
safety-critical drivetrain (i.e., engine, brakes, etc.) data
communications.

[]{#__RefHeading___Toc129324326 .anchor}Table 6 Family of SAE Vehicle
Network Standards

+----------------+-------------+-------------+-----------+-----------+
| **Physical     |             |             | **Co      | *         |
| Device**       |             |             | nnector** | *Wiring** |
+================+=============+=============+===========+===========+
| Application    | Com         | ![](medi    | ![](med   | ![](      |
| Software       | munications | a/image21.j | ia/image2 | media/ima |
|                | Protocol    | peg){width= | 2.jpeg){w | ge23.jpeg |
|                |             | "1.10416666 | idth="1.0 | ){width=" |
|                | Software    | 66666667in" | 326388888 | 0.9375in" |
|                |             | heigh       | 888889in" | hei       |
|                |             | t="0.552083 | hei       | ght="0.83 |
|                |             | 3333333334i | ght="0.32 | 333333333 |
|                |             | n"}Hardware | 777777777 | 33334in"} |
|                |             |             | 77778in"} |           |
+----------------+-------------+-------------+-----------+-----------+
| Management of  | Valid data  | Voltage     | \# pins   | \# wires; |
| device/data,   | and         | range       |           |           |
| e.g., SW to    | commands;   |             | Pin       | wire type |
| get/receive,   | data        | Definition  | a         |           |
| process, and   | definition; | T/F         | ssignment |           |
| transmit data  | error       |             |           |           |
| through comm.  | recovery;   |             | Outlet    |           |
| interface;     | rules for   |             |           |           |
|                | sending/    |             |           |           |
| HW             | receiving   |             |           |           |
| environmental  |             |             |           |           |
| rules          |             |             |           |           |
+----------------+-------------+-------------+-----------+-----------+
|                |             | En          |           |           |
|                |             | vironmental |           |           |
|                |             | spe         |           |           |
|                |             | cifications |           |           |
|                |             | temp.       |           |           |
|                |             | vibration,  |           |           |
|                |             | dust,       |           |           |
|                |             | EMI/RFI,    |           |           |
|                |             | etc.        |           |           |
+----------------+-------------+-------------+-----------+-----------+
| Defined        | Defined     | Defined     | Defined   | Defined   |
|                |             |             |           |           |
| J1587 / J1939  | J1708 /     | J1455       | J2496     | J2496     |
|                | J1939       |             |           |           |
| J1455          |             |             |           |           |
+----------------+-------------+-------------+-----------+-----------+

#### 2.6.1.4 Related Standards Efforts {#related-standards-efforts .Style-Heading-4-+-Justified}

There are many standards currently under development that include
transit systems. These standard efforts are divided into these three
areas:

> **ITS Standards:** Standards and emerging standards developed under
> the USDOT ITS Standards Program.
>
> **International Standard Organization Technical Committee 204 Working
> Group 8 (ISO TC 204 WG 8):** Standard development activities
> contributed and under discussion by several participating countries.
>
> **Geographic Information Framework Data Content Standard:
> Transportation / Transit (Part 7d):** An E-Government initiative to
> support the sharing of geospatial data sets and location services.

There are several standard development organizations in the U.S. that
are developing standards that may be used by transit agencies to
implement transit ITS. These standards are described below.

##### 2.6.1.4.1 Signal Control and Prioritization (NTCIP 1211) {#signal-control-and-prioritization-ntcip-1211 .Style-Heading-5-+-Justified}

The NTCIP Signal Control and Prioritization (SCP) 1211 standard defines
the functional entities of a Priority Request Generator (PRG) and a
Priority Request Server (PRS), the two "actors" that request and grant
priority treatment. The standard describes these actors in a logical
sense. For that reason, the SCP standard describes four scenarios that
correspond to the same scenarios referenced by the TCIP standard. The
NTCIP and TCIP Standard Development Organizations' working groups
coordinated the overlap in order to support the transfer of information
between the "transit" subsystems to the "traffic" subsystems. The hope
was that the similar approaches would ensure a high degree of
interoperability. The NTCIP SCP committee will eventually add a fifth
scenario to mirror the fifth TCIP scenario.

The NTCIP 1211 control and message formats are governed by NTCIP 8004
*Structure and Identification of Management Information*. NTCIP 8004 is
based on the RFC 1157 *Simple Network Management Protocol* and RFC 1155
*Structure and Identification of Management Information for TCP/IP Based
Internets.* NTCIP 8004 describes the managed objects found in the
Management Information Base (MIB). Managed objects are defined in the
Abstract Syntax Notion One (ASN.1) macro format and encoded in the NTCIP
1102 v.1.11 Octet Encoding Rules (OER).

The NTCIP standard is in the final stage of balloting and will be
promulgated as a standard by the summer of 2006.

##### 2.6.1.4.2 NTCIP 2306 Center to Center SOAP Interchange {#ntcip-2306-center-to-center-soap-interchange .Style-Heading-5-+-Justified}

The NTCIP 2306 standard provides a standards-based approach for
discovering and exchanging query/response messages between applications.
The standard, used for exchanging messages between ITS centers, is based
on the W3C standard SOAP[^51] and Web Services Descriptive Language
(WSDL). SOAP and WSDL are supported by most off the shelf applications
including Microsoft Excel. As such, the standard can be deployed in most
application environments.

The NTCIP standard is in the final stage of balloting and will be
promulgated as a standard by the summer of 2006.

##### 2.6.1.4.3 SAE Advanced Traveler Information Systems / Location Referencing Message Specification {#sae-advanced-traveler-information-systems-location-referencing-message-specification .Style-Heading-5-+-Justified}

The two Society of Automotive Engineers standards contain the data
dictionary and message sets needed to describe multimodal traveler
information (ATIS) and location references (LRMS) information. Both
these standards use the same base standards as those used by TCIP and
other ITS information standards: ASN.1 as the data description language
and XML as the means of encoding the messages. To this end, there is
syntactic interoperability among the various ITS interface standards.

The ATIS standard describes messages related to traveler requests and
responses on their multimodal travel plans including auto, bicycle,
walking, transit, ferry, and more. ATIS incorporates TCIP data elements
and data frames that are related to transit. Independently, the TCIP
standard incorporates ATIS modal trip messages, data elements, and
frames into the TCIP Passenger Information business area.

The TCIP standard also incorporates the LRMS data frames and elements as
a way to describe location. These data frames and elements are used
throughout the ITS messages, providing syntactic interoperability if not
standard ways of specifying location information.

In addition, several US DOT ITS sponsored standards such as the IEEE
1512 Incident Management and ITE Standard for Functional Level Traffic
Management Data Dictionary, in addition to TCIP, import both the ATIS
and LRMS data frames and elements into their specified messages. Both
these standards were balloted and approved in 2004.

Standard References:

Society of Automotive Engineers International (SAE). (2004-10). [Surface
Vehicle Standard J2266 - Location Referencing Message Specification
(LRMS)]{.underline}

Society of Automotive Engineers International (SAE). (February 2004).
[Surface Vehicle Standard J2354 -- Message Sets for Advanced Traveler
Information Systems (ATIS)]{.underline}

##### 2.6.1.4.4 Metadata and Archiving Standards / Standard Guide for Archiving and Retrieving ITS-Generated Data (E2259-03a) {#metadata-and-archiving-standards-standard-guide-for-archiving-and-retrieving-its-generated-data-e2259-03a .Style-Heading-5-+-Justified}

Each system described in this report generates information that may be
archived and later retrieved. For that purpose, metadata or data about
the data may be stored and archived for analysis and administration
purposes. The American Society of Testing and Materials (ASTM) developed
a standard that presents "desired approaches to be considered and
followed in planning, developing, and operating specific ADMS \[Archive
Data Management System\] for the archiving and retrieval of
ITS-generated data" \[from www.astm.org\]. The *E2259-03a Standard Guide
for Archiving and Retrieving ITS-Generated Data* generally requires that
three types of data be described as part of the event information:

> Administration
>
> Quality
>
> Lineage (source and life cycle information)

There are currently no guidelines for transit systems on how to use the
standard. Nevertheless, the approach described in the standard is
considered "best practices" in the information technology industry.

#### 2.6.1.5 ISO TC 204 Working Group 8 {#iso-tc-204-working-group-8 .Style-Heading-4-+-Justified}

The ISO TC 204 WG 8 on Public Transport and Emergency is working on
several standard efforts. The IFMS and TCIP (as a transit data interface
standard) areas were discussed in Sections 2.4.1.1 and 2.4.2.1 above.
Other areas under consideration include:

##### 2.6.1.5.1 Transmodel {#transmodel .Style-Heading-5-+-Justified}

Several European countries have offered Transmodel, a European Union
standard, as a conceptual data model to describe transit business
areas.[^52] The Transmodel data model uses entity-relationship diagrams
(ERD) and documents an extensive set of data requirement descriptions.
Transmodel differs from TCIP in that it uniquely and unambiguously
defines the data concepts and their relationship in the transit
information enterprise. The standard does not model data exchanges, and
to that end, the Transmodel conceptual model has a very different
purpose than TCIP.

The current version 6.0 is a mature model, based on the original version
that was developed over a ten-year period from 1990 to 2000. Transmodel
has spawned several interface standards that depend on the underlying
data model and requirements to describe the relationships among data
elements and concepts. The most accessible standard to a U.S. audience
is the United Kingdom's TransXchange, National Public Transport Access
Nodes (NaPTAN), and National Public Transport Gazetteer (NPTG)
standards. These XML-based interface formats support the exchange of
service data, bus stop inventory, and public transport places for all
registered transport companies. The data described by these standards
are implemented in the UK TransportDirect Information Portal.

The proposal for using Transmodel is still in its early phases. A
comparison between TCIP and Transmodel, as well as other national public
transport data interface standards, is currently underway.

##### 2.6.1.5.2 Standard Numbering System for Public Transport Stops (SNSPTS) {#standard-numbering-system-for-public-transport-stops-snspts .Style-Heading-5-+-Justified}

Although in its early stages of specification, the international
community recognizes the need to develop naming conventions and
approaches for the public to reference transit stops, be they bus stops,
stations, or ferry berths. Several proposals are being considered for
different regional levels, national, regional, and local. The
specification will be submitted as a new work item in 2006.

##### 2.6.1.5.3 PRESTO {#presto .Style-Heading-5-+-Justified}

The "Data Dictionary and Message Sets for Preemption and Prioritization
of Signal System for Emergency and Public Transport Vehicles (PRESTO)"
is a standard that addresses the message that is sent from a transit
vehicle to a signalized intersection requesting priority treatment. This
standard is based on the NTCIP 1400 TCIP series. The standard is a
Committee Draft (WD) that will be submitted as a Draft International
Standard (DIS) by fall 2006.

#### 2.6.1.6 GeoSpatial One Stop (GOS): Geographic Information Frame-work, Data Content Standard, Transportation: Transit (Part 7d)  {#geospatial-one-stop-gos-geographic-information-frame-work-data-content-standard-transportation-transit-part-7d .Style-Heading-4-+-Justified}

Driven by the E-Government standards initiative, the US Geologic Survey
(USGS), and US DOT Bureau of Transportation Statistics (BTS) \[now
GITA\], transit professionals from several agencies worked with experts
in the geographic industry to develop a standard that details the
requirements needed to exchange transit information that are tied to
geography or transportation networks. The result of this effort was a
combination of the Transmodel approach which describes a conceptual data
model, and the TCIP approach which documents the information exchange
needs between data source and application. Content described by the GOS
standard, because it is so closely tied to the Open Geodata Consortium
(OGC) location service specifications and Geographic Markup Language
(GML) standard, may be used by applications that support those industry
standards. The XML schema in GOS may use either LRMS or GML to represent
geospatial data (like a point, segment, or path).

The standard was submitted to ANSI for balloting in early 2006, and
should be approved later that year.

### 2.6.2 State of the Art {#state-of-the-art-4 .Style-Heading-3-+-Justified}

Many standards are under development or recently approved, although few
have actually been deployed. The only widely implemented standards are
the SAE 1708 family in buses and IEEE 1473 in trains. In addition, since
NTCIP 2306 is based on existing W3C standards that are widely
implemented across the IT industry spectrum, it may be viewed as a
mature standard. Table 7 summarizes the maturity level associated with
each standard set promulgated by the standard development organization
or set of standards.

[]{#__RefHeading___Toc129324327 .anchor}Table 7 Summaries of Standard
Efforts

+------------+-------------------------+------------------------------+
| **         | **Description**         | **Maturity and Deployments** |
| Standard** |                         |                              |
+============+=========================+==============================+
| Universal  | Card content, Fare      | Emerging. Several standards  |
| Transit    | Collection Subsystem    | are under development.       |
| Farecard   | and Clearinghouse       |                              |
| Standards  | Standards and           |                              |
| (UTFS)     | Guidelines              |                              |
+------------+-------------------------+------------------------------+
| NTCIP 1400 | Data Interface Standard | Implemented in Korean Trip   |
| series     |                         | Planning application using   |
| (TCIP 1)   |                         | ASN.1 encoding.              |
|            |                         |                              |
|            |                         | Several other agencies, such |
|            |                         | as SCAG and NJ Transit, are  |
|            |                         | using TCIP as a data         |
|            |                         | dictionary.                  |
+------------+-------------------------+------------------------------+
| APTA TCIP  | Message Exchange and    | Emerging. TCIP 2.4 was       |
| 2.x/3.0    | Dialog Standard         | demonstrated in the TRB IDEA |
|            |                         | Project 39, Dynamic          |
|            |                         | Timetable Generator -- see   |
|            |                         | Chapter 5.3.1.1 for more     |
|            |                         | information.                 |
+------------+-------------------------+------------------------------+
| SAE 1708   | Bus Standards:          | Adopted and implemented;     |
|            | multiplex               | J1939 is emerging for        |
|            | communications, cabling | transit adoption, although   |
|            | and message sets        | it is implemented by other   |
|            |                         | heavy-duty vehicle market    |
|            |                         | segment.                     |
+------------+-------------------------+------------------------------+
| IEEE RTVIS | Standards for rail      | 1473-1999: IEEE Standard for |
| (Rail      | vehicles. Over 21       | Communications Protocol      |
| Transit    | standards under         | Aboard Trains used onboard   |
| Vehicle    | development with 6      | trains. First implemented    |
| Interface  | published and approved. | RTVIS; deployed at several   |
| Standards) |                         | agencies, including NJ       |
|            |                         | Transit.                     |
+------------+-------------------------+------------------------------+
| Transmodel | A conceptual data model | Mature: Used as the          |
|            | developed by the        | conceptual data model for    |
|            | European standards      | several European exchange    |
|            | organization that       | standards including UK       |
|            | describes transit       | TransXchange, NaPTAN, and    |
|            | ITS-related business    | NPTG.                        |
|            | areas, including        |                              |
|            | personnel and           |                              |
|            | performance data        |                              |
|            | collection.             |                              |
+------------+-------------------------+------------------------------+
| NTCIP 1211 | Signal Control and      | Approved in January 2006.    |
|            | Prioritization          |                              |
+------------+-------------------------+------------------------------+
| SAE ATIS   | Advanced Traveler       | Approved, implemented in     |
|            | Information System      | Gary-Chicago-Milwaukee       |
|            |                         | (IDOT), San Francisco (MTC), |
|            |                         | Kansas City Scout Web site,  |
|            |                         | Nebraska Dept of Roads, and  |
|            |                         | Oregon DOT.                  |
+------------+-------------------------+------------------------------+
| SAE LRMS   | Location Referencing    | Approved, implemented in     |
|            | Method Standard         | ATIS and Incident Management |
|            |                         | systems                      |
+------------+-------------------------+------------------------------+
| NTCIP 2306 | Center to Center        | In balloting stage. Base     |
|            | message exchange        | standards, SOAP/WSDL are     |
|            | standard                | widely used throughout IT    |
|            |                         | industry                     |
+------------+-------------------------+------------------------------+
| E2259-03a  | Standard Guide for      | Balloted. Contains limited   |
|            | Archiving and           | guidance on transit          |
|            | Retrieving              | operations data archiving.   |
|            | ITS-Generated Data      |                              |
+------------+-------------------------+------------------------------+
| GOS        | Geospatial Content      | Emerging (demonstrated to    |
| Framework  | Standard that includes  | share geospatial information |
|            | transit layer along     | between two border counties  |
|            | with several other      | in California and Oregon)    |
|            | transportation layers.  |                              |
+------------+-------------------------+------------------------------+

Several demonstrations are implementing these standards; however, the
projects are too new to uncover challenges and lessons learned at this
stage.

### 2.6.3 Challenges and Lessons Learned {#challenges-and-lessons-learned-4 .Style-Heading-3-+-Justified}

Few standards are actually implemented. Many projects are specifying the
emerging standards and providing important lessons on implementation
strategies such as checking for overspecification or deficiencies in the
standards. From those that have demonstrated the standards, key lessons
include:

Always map requirements to the standards prior to specifying them in
procurements. The standard may not capture all the information needed by
an application or key elements may not be supported by the data sources
supplying the information.

Standards will not ensure that data are integrated across applications.
Several data sets may be vulnerable to inconsistency. (See reference for
"A Location Referencing Guidebook," Federal Transit Administration,
April 2005, below.)

Regional systems require regional data integration strategies. Many of
these issues and data sets that are vulnerable to inconsistency are
discussed in the Chapter 5.3, Transit Trip Information Infrastructure.
Standards are not a substitute for sound data management policies and
procedures.

Systems need multiple standards working together to ensure
interoperability. Understand how one standard interfaces with another to
work together.

Build on information technology (IT) standards such as W3C and OASIS to
ensure interoperability, reduce costs (because the tools are readily
available), and provide scalability and extensibility.

## 2.7 References  {#references .Style-Heading-2-+-Justified}

**Communications Technologies**

Fleishman, Glenn, "Back to the Future: New Wi-Fi Bridges Use 1999
Standard,"
[www.oreillynet.com/pub/a/wireless/2003/08/28/wireless_bridging.html](http://www.oreillynet.com/pub/a/wireless/2003/08/28/wireless_bridging.html),
08/28/2003.

Kain, C, Mitretek, Inc., Commercial Mobile Radio Systems Applications in
Public Transit, February 2003, 63 pp.

Lok, Corie, "Instant Networks: Just Add Software." *Technology Review*,
June 2005, p. 28.

P.B. Farradyne. "VEHICLE INFRASTRUCTURE INTEGRATION (VII), VII
Architecture and Functional Requirements," FHWA, April 12, 2005, p. 87.

"Understanding Wi-Fi and WiMAX as Metro-Access Solutions." Intel,
January 1, 2004. 16 pp.
[www.bitpipe.com/rlist/term/WiMAX.html](http://www.bitpipe.com/rlist/term/WiMAX.html).

Walker, Jonathan, "[Wi-Fi Mesh Networks, the Path to Mobile Ad
Hoc](http://www.wi-fitechnology.com/Wi-Fi_Reports_and_Papers/Wi-Fi_Mesh_Networks.html)."

[www.wi-fitechnology.com/Wi-Fi_Reports_and_Papers/Introduction_to_Wi-Fi_Mesh_Networks.html](http://www.wi-fitechnology.com/Wi-Fi_Reports_and_Papers/Introduction_to_Wi-Fi_Mesh_Networks.html).

**Geographic Information Systems**

\"Defining Geographic Locations of Bus Stops, Routes and Other Map Data
for ITS, GIS and Operational Efficiencies: Best Practices for Using
Geographic Data in Transit: A Location Referencing Guidebook," Federal
Transit Administration, April 2005. 211 pp.

[[www.fta.dot.gov/16734_16869_ENG_HTML.htm]{.underline}](http://tsconsortium.org/LRG_FinalPublication.pdf).

"Geographic Information Systems Applications in Transit." Transit\
Cooperative Research Program, Washington, DC (2005).  TCRP Synthesis 55.

<http://trb.org/publications/tcrp/tcrp_syn_55.pdf>.

"Transit Communications Interface Profiles. Draft Standard Version
2.7.1," Section 5.10, Concept of Operations for the Spatial Data
Management Process. APTA, 2005.

[www.apta.com/about/committees/rsrchtec/tcip/](http://www.apta.com/about/committees/rsrchtec/tcip/).

"2003 National Geospatial Information Systems Survey Results."
Bridgewater State College, MA.
[www.e-transit.org/survey/20022003/](http://www.e-transit.org/survey/20022003/).

**Other**

"Bus Stop Inventory Guidebook." Transit Standards Consortium, August
2000. 40 pp.

<http://tsconsortium.org/BusStopInventoryBestPracticesandGuidlines.pdf>.

"Building Quality Intelligent Transportation Systems Through Systems
Engineering," Report No. FHWA-OP-02-046, Department of Transportation
Intelligent Transportation Systems Joint Program Office, April 2002.

Casey, Robert F., "What Have We Learned About Advanced Public
Transportation Systems?" Volpe Transportation Systems Center, Cambridge,
MA (2000), Chapter 5.
[www.itsdocs.fhwa.dot.gov/jpodocs/EDLBrow/@@101!.pdf](http://www.itsdocs.fhwa.dot.gov/jpodocs/EDLBrow/@@101!.pdf).

"Facilitating Integrated ITS Deployment Program." Office of Operations,
FHWA. Facilitating Integrated ITS Deployment Program is responsible for
developing, and supporting implementation of, Intelligent Transportation
System (ITS) policies and programs aimed at increasing the level of
integrated ITS deployment throughout the country.
[www.ops.fhwa.dot.gov/int_its_deployment/index.htm](http://www.ops.fhwa.dot.gov/int_its_deployment/index.htm).

Franzese, Oscar, Tykey Truett, and Edmond Chin-Ping Chang, "Shared
Communications: Volume I. A Summary and Literature Review." Oak Ridge
National Labs.
[www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/14075.htm](http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/14075.htm).

"ITS Integration Component of the ITS Deployment Program, January 2005
Online Edition." USDOT's summary of ITS integration projects is
available at the following Web site. It includes an Introduction, a
Project by State page, and List by Project Title.

[www.its.dot.gov/resources/IntegrationProject/index.htm](http://www.its.dot.gov/resources/IntegrationProject/index.htm).

Miami-Dade Transit Authority. "IT/ITS Strategic Plan 2003-2008, Vol.
I-II." Miami-Dade Metro Transit, January 2004. "Intelligent
Transportation Systems (ITS) 2003-2008." January 2004.
[www.co.miami-dade.fl.us/transit/transit_reports.asp](http://www.co.miami-dade.fl.us/transit/transit_reports.asp).

Mitretek Systems, "e-Transit: Electronic Business Strategies for Public
Transportation, Volume 5 - Concept for an e-Transit Reference Enterprise
Architecture." TCRP Report 84, Transportation Research Board,
Washington, DC (2004), 41 pp.

<http://gulliver.trb.org/publications/tcrp/tcrp_rpt_84v5.pdf>.

National Transit Institute: "Managing Information for Success: Your Role
in a Changing Business." January 2003.

"OMB Enterprise Architecture Assessment Framework 2.0, Federal
Enterprise Architecture Program EA Assessment Framework 2.0." December,
2005.
[www.cio.gov/documents/OMB_EA_Assessment_Framework_2.pdf](http://www.cio.gov/documents/OMB_EA_Assessment_Framework_2.pdf).

"ORNL ITS Deployment Tracking." Oak Ridge National Laboratory, 2004.

<http://itsdeployment2.ed.ornl.gov/its2004/SurveyOutline.asp>

Steven H. Spewak with Steven C. Hill, "Enterprise Architecture Planning,
Developing a Blueprint for Data, Applications, and Technology." John
Wiley and Sons, Inc. September 1993.

"Systems Engineering Guidebook for ITS" Version 1.0c. Sponsored by the
Federal Highway Administration and the California Department of
Transportation's Division of Research and Innovation. January 2005.

Technology Solution Providers, "Assessment of ITS Deployments: Draft
Final Report for Federal Transit Administration (FTA)." May 2005.

# Chapter 3 Fleet Management

## 3.1 Introduction  {#introduction .Style-Heading-2-+-Justified}

The term "Fleet Management" refers to the processes of planning,
supervising, and optimizing the delivery of transit services, and also
to the maintenance of vehicles providing those services. Automatic
Vehicle Location (AVL) and Computer Aided Dispatch (CAD) systems are
examples of technologies that facilitate the management of transit fleet
operations, provide up-to-date information on vehicle locations to
assist transit dispatchers, and inform travelers of route status.[^53]
Maintenance monitoring technologies allow for automatic collection and
reporting of vehicle maintenance and condition information.[^54]
Moreover, a variety of Intelligent Transportation Systems (ITS)
technologies including those that provide data from AVL/CAD systems and
Automatic Passenger Counters (APC) can assist in the planning of new and
existing transit services.[^55]

ITS Fleet Management technologies are vast and include in-vehicle,
field, and operations center systems. Integration of the various
technologies and associated sensors allows individual technologies such
as AVL, Wireless Communications, APCs, Transit Signal Priority (TSP),
and others to provide benefits greater than any one technology could
provide individually. Figures 13 and 14 illustrate many of the
technologies and processes that are used and integrated into bus fleet
management operations.

![](media/image24.jpeg){width="6.4944444444444445in" height="4.73125in"}

[]{#__RefHeading___Toc129324155 .anchor}Figure 13 Fleet Management
State-of-the-Art

ITS Fleet Management provides the means by which transit agencies can
"bring it all together" for customers. In addition to obvious service
supervision and maintenance management benefits made possible by the
remote monitoring of vehicle position, on-time performance, and
condition of various vehicle mechanical systems, Fleet Management
technologies provide the basis for the various real-time incident
management and passenger information applications discussed elsewhere in
this report.

![](media/image25.jpeg){width="6.495833333333334in"
height="4.458333333333333in"}

[]{#__RefHeading___Toc129324156 .anchor}Figure 14 Fleet Management
In-Vehicle Technologies

Fleet management can encompass many forms of vehicle and system control
operations. For purposes of this report, ITS Fleet Management systems
have been divided into four major categories:

> Service Planning Support Systems;
>
> Transit Priority Treatment;
>
> Maintenance Management Systems; and
>
> Transportation Operations Systems.

Transportation Operations Systems have been further divided into "Rail
Operations Control Systems," "Bus Operations Systems," "Other Operations
Systems" (i.e., passenger, facilities, HOV, multimodal), Dynamic
Scheduling, and Paratransit Operations Systems.

## 3.2 Service Planning Support Systems  {#service-planning-support-systems .Style-Heading-2-+-Justified}

### 3.2.1 Technology Description {#technology-description-4 .Style-Heading-3-+-Justified}

Service Planning Support systems include systems and business
applications that support and process the information that flows to and
from the fleet management systems. Since the Fleet Management System
monitors actual service against expected service to optimize, control,
and recover from incidents, the system is driven by service planning
data concerning schedules, passenger facilities, network infrastructure,
passenger loads, vehicle assignments, and vehicles. These data sets may
require extensive processing on a monthly, weekly, or daily basis. This
category of ITS applications includes developing the data sets related
to the service plans (e.g., schedules) that can be processed by
downstream systems used by customers, operators, and vehicles.
(Additional details about these data sets are found in Chapter 2,
Integration.)

Further, the various fleet management systems will produce gigabytes of
transit performance and event data in a very short time. As a result,
associated analysis tools must have the capacity to process and
interpret these large volumes of data to support service performance and
ridership reporting. The possibilities for deriving valuable information
from these data are virtually unlimited and represent a critical element
of a service planning support infrastructure.

Service Planning Support technologies include:

> APC --- treadle mats, horizontal or vertical infrared beams, or
> machine vision applications that record the time, location and number
> of boarding and alighting passengers (and thus passenger load) at each
> stop;
>
> Automatic Vehicle Location (AVL) --- specifically, schedulers need
> archived running time and headway reliability data from the AVL
> system;
>
> Route and pattern tracing tools (for onboard configuration data
> preparation);
>
> Performance data input to scheduling (as an interface only);
>
> Passenger facility planning tools (includes Bus Stop Inventory and
> field data collection applications);
>
> Reporting and visualization tools (decision support);
>
> Operator assignment management tools; and
>
> Electronic Scheduling Systems.

All of the Service Planning Support technologies mentioned above are
commercially available.

### 3.2.2 State of the Art {#state-of-the-art-5 .Style-Heading-3-+-Justified}

State-of-the-art Service Planning Support systems are currently
distinguished by such features as:

> Passenger count accuracy in the two to three percent error range
> (which is about three times better than that commonly obtained with
> conventional manual counting procedures -- commonly referred to as
> ride checks), even in vehicles with wide doorways, multiple passenger
> streams, and highly crowded loading conditions;
>
> Automatic download and processing of running time and ridership data;
>
> Automatic verification of reported route, run, and trip information
> based on actual path traveled;
>
> Automatic passenger count balancing;
>
> Automatic data cleansing to identify and filter data of questionable
> quality;
>
> Automatic identification and reporting of failed passenger count
> sensors and equipment;
>
> Seamless integration with third party data visualization, statistical
> analysis, and business intelligence tools;
>
> Statistical ridership summaries by street, stop, route, trip, day,
> time of day, timepoint interval, and municipality;
>
> Automatic calculation of running time distribution and variation by
> time of day for input into scheduling and run-cutting systems;
>
> Automatic calculation of pre-trip recovery time required to ensure a
> given probability of on-time departure as a function of scheduled
> running time and observed running time variability;
>
> Ability to respect stop occupancy and capacity constraints during
> scheduling; and
>
> Integrated stop inventory maintenance.

State-of-the-art deployment examples:

> King County Metro Transit, Seattle, WA
>
> While not the most advanced in terms of technology, King County Metro
> defines current state-of-the-art in terms of APC utilization,
> performance, and lessons learned in the U.S. Characteristics include:
>
> Considered by many to have one of the most highly developed APC data
> analysis and reporting programs, and most systematic use of APC data
> in the U.S.;
>
> Data are currently downloaded manually (will automate in future);
>
> Uses a mix of legacy treadle mat and newer infrared sensor
> technologies;
>
> 219 of its buses are APC equipped (15 percent of fleet; roughly
> average for a partial fleet implementation);
>
> Uses automatic balancing and tuning of APC passenger counts;
>
> APC counts are used for service planning, AVL running times are used
> for scheduling; and
>
> There are currently no automated ties between APC and AVL systems
> (though both use same radio beacon "signposts" for position
> determination).
>
> New Jersey Transit Corporation (NJ TRANSIT), Newark, NJ
>
> Though not yet widely deployed or used within the agency, NJ TRANSIT's
> APC technology is perhaps the most advanced in the U.S. The system
> makes use of:
>
> Overhead infrared sensor technology;
>
> Automatic data download;
>
> Automatic upload of updated vehicle software and data collection
> parameters;
>
> Automatic equipment diagnostics and failure reporting;
>
> Automatic data cleansing;
>
> Standards-based modular architecture;
>
> Multivendor interchangeable components;
>
> Seamless integration with third party database, reporting, and
> analysis tools; and
>
> Eight pilot buses (6 percent at one garage) and 17 low-floor
> articulated light rail cars (one complete light rail line) are APC
> equipped.

### 3.2.3 Emerging Trends {#emerging-trends-3 .Style-Heading-3-+-Justified}

Most commercially available scheduling and run-cutting systems offer
table-based facilities for maintenance of stop inventory and pattern
stop list data within the vendor's proprietary database. Many users,
however, have expressed a desire to be able to maintain these data using
a map-based tool instead. Unfortunately, stop and pattern data contained
in these proprietary databases are not readily accessible to the third
party GIS (geographical information system) tools that agencies would
like to be able to use. As an interim measure, work is currently
underway by at least one vendor to automate an export/import process
that would allow the tabular stop and pattern data to be maintained in a
separate GIS database.

### 3.2.4 Challenges and Lessons Learned {#challenges-and-lessons-learned-5 .Style-Heading-3-+-Justified}

Optimizing the data processing and reporting capabilities associated
with an APC system to obtain ideal performance at a specific agency's
operating environment may take years. Persistence is essential for
meeting this challenge and achieving the desired results. As an example
of the persistence required, operational data from AVL, APC, fare
collection, TSP, and others must be cleansed and filtered before the
data can be considered suitable for reporting. Additionally, route and
trip attributions must be verified and anomalous data corrected or
removed.

Agencies that have begun to share schedules and stop inventories
electronically, either with other agencies or with other systems within
their own agency, are finding that their efforts are being hindered by a
lack of data consistency, continuity, and completeness. These agencies
have found that the first step toward ITS implementation is to define an
enterprise data model for stop, pattern, and schedule information,
together with a consistent business process for stop and schedule data
maintenance and updating.

## 3.3 Transit Priority Treatment  {#transit-priority-treatment .Style-Heading-2-+-Justified}

### 3.3.1 Technology Description {#technology-description-5 .Style-Heading-3-+-Justified}

TSP systems use sensors to detect approaching transit vehicles and alter
signal (i.e., traffic light) timings to improve transit performance and
reliability.[^56]

Transit priority treatment involves identifying approaching transit
vehicles, determining whether priority is desired and the level and type
of priority to be granted, and executing the appropriate signal priority
strategy. Available strategies include extending the green light phase
to allow transit vehicles to travel through, providing an early green
light to allow transit vehicles to spend less time at an intersection,
dedicated queue bypass lanes, and providing a special "buses only"
signal where buses stop on the near side shoulder to allow buses right
of way for rejoining the normal travel lanes. Other transit priority
treatments include bus only travel lanes, and ordinances requiring that
motorists yield to transit vehicles.

In theory, transit priority can be managed either at the intersection
level (i.e., a "distributed" approach where buses autonomously request
priority from upcoming intersections) or at the system level (i.e., a
"centralized" approach where the transit management center requests
priority from the traffic management center). In practice, according to
the agencies surveyed for this report, transit priority has thus far
most often been implemented using the distributed approach.

While transit priority has occasionally been implemented as an outright
preemption of the normal traffic signal timing (most often in
conjunction with commuter rail or light rail), or with a conditional
priority set so high as to amount to outright preemption, this is not
the norm. In most implementations, the logic for determining the level
and type of priority to be granted can be quite complex, involving such
variables as traffic volumes, queue lengths, intersection loading,
vehicle type, direction, headway, persons on board, presence of a
near-side stop, transit vehicle speed, frequency of priority requests,
time since last priority, cycle length, schedule deviation, anticipated
effect on overall signal coordination, and the point in the signal
timing cycle when the request is first detected.

Transit Priority Treatment technologies include:

> Vehicle to wayside communications (radio, optical, tag readers,
> inductive loop, wireless fidelity \[WI-FI\], etc.);
>
> Signal Controller and Controller Cabinet;
>
> Center-to-Field communications; and
>
> Center-to-Center communications.

All of the Transit Priority Treatment technologies described above are
commercially available and have been successfully deployed.

### 3.3.2 State of the Art {#state-of-the-art-6 .Style-Heading-3-+-Justified}

In addition to the various non-technical strategies available, most
current implementations of ITS transit priority treatment provide
conditional transit signal priority for transit vehicles approaching an
intersection. The state of the art in TSP is characterized by a
rule-based system that determines the need for a transit vehicle to be
granted priority treatment. These rules consider the presence of a
priority request by a transit vehicle, whether the bus/light rail
vehicle is late or other criteria, and the capabilities of the signal
controller in determining whether the request for priority can meet the
operational policies of the traffic control agency (i.e., if the
controller can extend or shorten a green light while not skipping any
phases, braking coordination, etc.).

State-of-the-art TSP programs are distinguished by such features as:

> Senior staff members have extensive background in Traffic Engineering;
>
> Intersection controllers with the ability to support highly
> conditional priority algorithms based on traffic volumes, queue
> lengths, intersection loading, vehicle type, direction, headway,
> persons on board, frequency of priority requests, time since last
> priority, schedule deviation, and the point in cycle when bus is
> detected;
>
> Automatic logging of priority requests and actions taken;
>
> Automatic sensitivity analysis for identification of critical time
> point interval running times with greatest impact on vehicle
> requirements (i.e., in cases where signal priority, timing
> adjustments, queue bypass or bus only lanes might be most effective in
> reducing operating costs); and
>
> Support for "what if" blocking and run-cutting simulations to identify
> likely impacts of transit signal priority and skip stop operation with
> respect to peak vehicle requirements.

State-of-the-art deployment examples:

> Pierce Transit, Tacoma, WA
>
> Characterized by:
>
> Few jurisdictions; and
>
> Nearly unconditional priority.
>
> King County Metro Transit, Seattle, WA
>
> Characterized by:
>
> Many jurisdictions;
>
> Highly conditional priority;
>
> Highly intelligent transit signal priority processors housed in the
> signal controller cabinet;
>
> Interface between the transit signal priority processor with the
> signal controller; and
>
> Communication from bus to transit signal priority processor to signal
> the presence of a bus near the intersection.

### 3.3.3 Emerging Trends {#emerging-trends-4 .Style-Heading-3-+-Justified}

Bus priority ordinances in New Jersey, Florida, Washington, and Oregon
require motorists to yield the right-of-way to buses reentering traffic
after picking up or discharging passengers. Coupled with aggressive
enforcement (possibly aided by onboard digital video recordings),
especially in areas where more time is lost trying to get back into the
traffic stream than from waiting at traffic lights per se, such statutes
might be expected to provide significant running time savings.

At least one signal controller manufacturer now offers controller
modules with the intelligence required to actively manage signal
priority in an effective manner without disrupting the overall traffic
flow; other manufacturers are expected to follow. As traffic engineers
become more familiar with this capability, resistance to signal priority
implementation may decrease.

### 3.3.4 Challenges and Lessons Learned {#challenges-and-lessons-learned-6 .Style-Heading-3-+-Justified}

> The level of policy support for Transit Priority Treatment programs
> varies by jurisdiction. Ultimately, however, obtaining support from
> local traffic engineers may present a greater challenge than the
> policy support.
>
> Making TSP or TPT acceptable to the region's traffic engineers
> involves funds that may not be available. For example, there are costs
> associated with modifying controllers to add the intelligence
> necessary to effectively manage priority calls and with modifying
> controllers and central systems to track and report call performance.
>
> Agencies have found that even with a highly conditional priority
> strategy, average travel time savings on the order of five percent can
> be achieved. Perhaps more important, running time variation can be
> reduced, making schedules more reliable and allowing shorter recovery
> times between trips.
>
> Transit agencies need to assist local traffic engineers through the
> learning curve; they are not necessarily familiar with the ability of
> modern systems to manage signal priority without completely disrupting
> traffic flow. Hosting seminars at local meetings of the Institute of
> Transportation Engineers (ITE) is an obvious first step.
>
> Interagency agreements structured so that municipalities can feel they
> have the option to "walk away" if things do not work out may go a long
> way toward fostering acceptance of an initial signal priority
> deployment. Under this model, if a city chooses to cancel the project
> the agency simply takes back the equipment.
>
> Agencies also need to help their schedulers through the learning
> curve; due to fear of issuing scheduled running times that turn out to
> be too short, there is typically great resistance to actually
> incorporating all of the available travel time savings into published
> schedules.
>
> Seeking regional consensus for incorporation of signal priority into
> large signalization projects can add years to the implementation
> effort. It may be better to proceed with a small demonstration project
> first (i.e., one or two intersections) and then expand the effort if
> successful.
>
> Knowledge of traffic engineering, intersection controllers, and tools
> is invaluable to the process. The knowledge allows the agency to
> understand traffic engineers' terminology and to address their issues
> and concerns.
>
> When deploying signal priority, agencies should insist on sharing the
> maintenance. If not there already, agencies should maintain the
> network and the application software, and oversee maintenance
> management, failure detection, and reporting. In addition, regardless
> of who actually pays for the system, it is recommended that the city
> own (and maintain) the hardware located on the street as ownership of
> the field equipment will get the city vested in the system. It is also
> important to ensure that the transit signal priority processor can
> actually fit inside the existing intersection controller cabinet
> because not all will.
>
> Establishing and maintaining communications infrastructures in the
> field can be difficult, both technically and institutionally.
> Therefore, it is recommended that a senior-level traffic engineer be
> hired to provide assistance. Transit agency personnel do not typically
> have the required traffic engineering vocabulary and credibility to
> facilitate the deployment of signal priority systems.
>
> Many state departments of transportation are realizing the benefits
> made possible from upgrading their communications and intersection
> capabilities, updating signal controller cabinets, implementing closed
> loop control, and so on. A good time to discuss TSP and TPT with
> traffic departments is when they are planning to upgrade their
> intersections or traffic signal systems.

## 3.4 Maintenance Management Systems  {#maintenance-management-systems .Style-Heading-2-+-Justified}

### 3.4.1 Technology Description {#technology-description-6 .Style-Heading-3-+-Justified}

Maintenance Management Systems perform many tasks, including the
monitoring of major onboard vehicle components to provide warnings of
failures and to help managers improve the effectiveness and efficiency
of maintenance operations.

Maintenance Management Systems technologies include:

> Electronic inspection aids (providing voice and graphical instruction
> for vehicle and component inspection and troubleshooting);
>
> Fluids management systems;
>
> Inventory management systems;
>
> Interactive maintenance training systems;
>
> Remote vehicle diagnostics;
>
> Maintenance records management systems;
>
> Interactive electronic parts manuals;
>
> Warranty monitoring and management;
>
> Electronic component tagging (radio frequency identification --- RFID)
>
> Vehicle health monitoring; and
>
> Electronic defect cards (allowing operators to report defects through
> an onboard data terminal).

All of the Maintenance Management System applications described above
are commercially available.

### 3.4.2 State of the Art {#state-of-the-art-7 .Style-Heading-3-+-Justified}

State-of-the-art Maintenance Management Systems are distinguished by
such features as:

> Automatic capture of propulsion, braking, and other onboard equipment
> status, alarm, and health measurement records that are tagged with
> current odometer, time, and location information;
>
> Automatic capture of component serial number and software version
> identification for all installed onboard electronic systems;
>
> Component serial number, software version, alarm and health
> information that is automatically transferred to the maintenance
> management system;
>
> Electronic tagging of refurbishable mechanical and electrical
> components such as wheels, actuators, alternators, radiators, and so
> on;
>
> Vehicle health and alarm information automatically analyzed to
> identify failed, failing, and misadjusted components;
>
> Operator-identified equipment defect information captured
> electronically onboard the vehicle;
>
> Operator-identified equipment defect information automatically
> transferred from vehicle to the maintenance management system in
> advance of vehicle arrival at the maintenance facility;
>
> Work orders and associated tools and parts lists required for
> corrective maintenance automatically generated in advance of vehicle
> arrival at the maintenance facility;
>
> Automatic identification of repeat failures of individual components;
>
> Automatic identification of warranty coverage of individual
> components;
>
> Full range of real-time equipment status and diagnostics information
> available remotely;
>
> Single-point-of-maintenance data access for all systems on a given
> vehicle; and
>
> Vehicle health and exception information for all installed systems
> (including propulsion, braking, fare collection, electrical, HVAC,
> wheelchair lift, AVL, etc.) centrally accessible via the onboard
> Mobile Data Terminal (MDT) and voice annunciator.

State-of-the-art deployment examples include:

Los Angeles County Metropolitan Transportation Authority, Los Angeles,
CA

> Features include:
>
> 2,400 buses equipped with onboard Maintenance Management Systems (100
> percent of fleet);
>
> Integration with maintenance and material management systems; and
>
> Powertrain alarms transmitted in real time.

Pierce Transit, Tacoma, WA

> Features include:
>
> 100 vehicles equipped with comprehensive maintenance data acquisition
> (40 percent of fleet).

New Jersey Transit Rail Operations, Newark, NJ

> Features include:
>
> Remote diagnostics and automatic real-time failure notification on 60
> electric locomotives; and
>
> Single-point--of-maintenance data access on more than 200 commuter
> railcars.

Chicago Transit Authority, Chicago, IL

> Features include:
>
> 2000 buses equipped with onboard Maintenance Management Systems (100
> percent of fleet);
>
> Powertrain (engine, transmission, brakes, etc.) alarms transmitted in
> real time; and
>
> Voice annunciation system used to report health status of ITS
> components.

### 3.4.3 Emerging Trends {#emerging-trends-5 .Style-Heading-3-+-Justified}

Maintenance Management Systems are doing more than simply transmitting
powertrain alarms. They are beginning to capture a variety of vehicle
operating conditions such as temperatures, pressures, and voltages to
support trend analysis for condition-based maintenance and prediction of
impending failures.

### 3.4.4 Challenges and Lessons Learned {#challenges-and-lessons-learned-7 .Style-Heading-3-+-Justified}

Tracking and identifying patterns of equipment failures is one of the
biggest challenges facing Maintenance Management Systems. Being able to
detect and repair a component failure is relatively easy. It is quite
another matter to be able to recognize that specific units have been
exhibiting a pattern of repeat failures --- indicating that previous
repairs have addressed only a symptom and that the root cause has yet to
be uncovered. Agencies with state-of-the-art applications of Maintenance
Management Systems have learned that tagging of field-replaceable units
with electronic serial numbers that are scanned upon entry to the shop
can greatly improve both their ability to detect repeat failures and
their ability to track repair facility throughput and performance.

## 3.5 Transportation Operations Systems {#transportation-operations-systems .Style-Heading-2-+-Justified}

### 3.5.1 Technology Description {#technology-description-7 .Style-Heading-3-+-Justified}

Transportation Operations Systems are the so-called backend systems
housed at the agency that support real-time operations of transit
fleets. For this report, transportation operations systems have been
grouped in the following categories:

> Rail Operations Control Systems
>
> Bus Operations Systems
>
> Other Operations Systems (Passenger, facilities, HOV, multimodal)
>
> Dynamic Scheduling and Paratransit Operations Systems

A typical state-of-the-art transportation operations system is
illustrated in block diagram form in Figure 15 below:

> ![](media/image26.jpeg){width="6.4944444444444445in"
> height="4.513194444444444in"}

[]{#__RefHeading___Toc129324157 .anchor}Figure 15 Transportation
Operations System Block Diagram

#### 3.5.1.1 Rail Operations Control Systems {#rail-operations-control-systems .Style-Heading-4-+-Justified}

Rail Operations Control Center Systems are comprised of computer
software for rail control center functions that include train movement,
power management, status monitoring, emergency response, estimated time
of arrival (ETA) prediction, and decision support. Technology
applications include:

> Electronic vehicle identification;
>
> Communications-based train control (CBTC);
>
> Video processing;
>
> SCADA (supervisory control and data acquisition);
>
> Center-to-center communications;
>
> Consist management;
>
> Crew management; and
>
> Interfaces to other fixed-end systems with need for real-time
> information.

The Rail Operations Control Center Systems described above are
commercially available and widely deployed.

#### 3.5.1.2 Bus Operations Systems {#bus-operations-systems .Style-Heading-4-+-Justified}

Bus Operations Control Center Systems are comprised of computer software
that assists transit agencies in operating fixed-route bus service. They
include ETA prediction functions such as vehicle location, route and
schedule adherence, connection protection, communications management,
and decision support. The Bus Operations System may be located at a
fixed location or be portable. Technology applications include:

> Computer Aided Dispatch (CAD), incident management and reporting,
> supervisor and maintenance dispatch modules, and remote CAD systems;
>
> Vehicle and operator assignment and dispatch;
>
> Yard/garage parking management; and
>
> Interfaces to other fixed-end systems with need for real-time
> information.

The Bus Operations Control Center Systems described above are
commercially available and widely deployed.

#### 3.5.1.3 Paratransit Operations Systems {#paratransit-operations-systems .Style-Heading-4-+-Justified}

Paratransit Operations Systems include tools for the dispatch and
operation of paratransit services that accommodate both standing orders
and immediate requests. The system and its associated business processes
may also support route deviation service and intermodal/interagency
connections. Although eligibility, reservations, and billing systems of
individual paratransit service providers are not specifically included
in this category, information from scheduling and dispatch may be
integrated back into the service providers' management information,
billing, and accounting functions.

The Paratransit Operations Systems described above are commercially
available and widely deployed.

#### 3.5.1.4 Other Operations Systems {#other-operations-systems .Style-Heading-4-+-Justified}

Other operations systems include Ferry Dispatch Systems, Passenger
Operations Centers (i.e., those that monitor passenger facilities for
elevator outages), and other centers where fleets of equipment are
managed. These systems provide information on incident and facility
outages to senior management, passengers at facilities, special
announcements, and public relations (for media). Also included are HOV
and multimodal operations (if run by transit).

The systems described above are all commercially available.

### 3.5.2 State of the Art {#state-of-the-art-8 .Style-Heading-3-+-Justified}

The state-of-the-art in Transportation Operations Systems provides
supervisory and management personnel with a complete "picture" of the
current status of the entire transit operation. Moreover,
state-of-the-art systems present this total operations picture in an
integrated way that makes it easy to understand and easy to formulate an
appropriate response. In some cases, as with continual timing
adjustments to prevent minor schedule and headway deviations from
becoming big ones, response may even be fully automated. In other cases,
systems may present a choice of recommended actions that an operator can
choose to execute or not. It should be noted that the capabilities and
performance available in state-of-the-art operations control solutions
are truly extraordinary. In fact, relatively few agencies may have a
real need (or budget) for all of the features available in this area.

State-of-the-art transportation operations systems are distinguished by
a wide variety of advanced features such as those summarized below:

> [Institutional features include]{.underline}:
>
> Statistically valid scheduled recovery times at the end of each
> scheduled trip (non technical enabling characteristic);
>
> Gap vehicles (i.e., spare vehicles available to plug developing gaps
> in service) (non technical enabling characteristic);
>
> Integrated dispatch, communications, passenger information, incident
> management, and security functions;
>
> Sharing of information, video, and display assets with other transit
> and public safety agencies specifically for incident management and
> Amber Alert functions; and
>
> Element of comprehensive integrated technology plan (non-technical
> enabling characteristic).
>
> [Communications features include]{.underline}:
>
> Automatic monitoring of communications system performance,
> availability, communications coverage, and throughput and "request to
> talk" response time;
>
> Continually updated virus protection;
>
> Strict control of computing machinery and data networks, network
> firewalls, access controls, restricted administrative privileges,
> unused communication ports locked down, and so on;
>
> Digital recording of all voice communications;
>
> Logging of all data messages sent to and from the control center; and
>
> Standards-based data exchange with communications protocol/technology
> decoupled from Control Center software, allowing single control center
> to coordinate operations of multiple divisions or service providers
> having different communications methods (e.g., cellular, satellite,
> 800 MHz, GSM) and in-vehicle technologies (e.g., from different
> vendors).
>
> [Infrastructure features include]{.underline}:
>
> Redundancy of all critical functions and communications, with
> automatic failover;
>
> Hardened, secure communications with diverse redundant paths;
>
> Hardened control center environmental systems;
>
> Accommodations and provisions for extended shift operations;
>
> Physical access controls;
>
> Uninterruptible power supplies with multiple backup power sources;
>
> Physically separate backup control facility with redundant power,
> processors, and communications; and
>
> Separate test environment with access to live data feeds.
>
> [Operations Control and Supervision features include]{.underline}:
>
> Configurable automatic reporting of component failures, system
> performance exceptions, service exceptions, and user exceptions and
> overrides;
>
> Headway monitoring;
>
> Automatic tracking of hours in service for vehicle and control center
> operators;
>
> Automatic exception notifications for route, schedule, and headway
> deviations, operators nearing hours in service limits, vehicles that
> will not arrive in time to make scheduled turn, vehicles lacking
> sufficient fuel for next scheduled trips, vehicles with mechanical
> problems, and others;
>
> Operations decision support with automatic response within defined
> limits for headway and schedule adherence;
>
> Terminal decision support with automatic response within defined
> limits for service continuity;
>
> Transfer connection protection;
>
> Route adherence monitoring;
>
> Integration with maintenance management;
>
> Playback capability;
>
> Interactive training functions; and
>
> Configurable user interface.
>
> [Incident Management and Reporting features include]{.underline}:
>
> Onboard video surveillance and recording with ability to display
> real-time video at control center and in police and supervisory
> vehicles operating near the transit vehicle;
>
> Facility video surveillance and recording with ability to display
> real-time video at control center;
>
> Video processing (machine vision) to identify exception conditions at
> facilities (e.g., overcrowded platforms, dropped bag, etc.), and
> target operator attention;
>
> Silent alarm with covert audio and video transmission to control
> center;
>
> Automatic detection of unauthorized vehicle movements; and
>
> Ability to retrieve digital imagery and aerial photography, and
> identify emergency access routes (especially for rail) for any point
> on any line to support incident management and operator training.
>
> [Data Archive features include]{.underline}:
>
> Automatic detection and logging of component failures, service
> exceptions, user exceptions, and overrides;
>
> Automatic association of reported vehicle location and delays with
> specific GIS roadway links, stops, mileposts, and intersections;
>
> Automatic logging of missed trips and extra trips operated in addition
> to schedule; and
>
> Operational data store with an interface to archived enterprise data.
>
> [Passenger Information features include]{.underline}:
>
> Automatic tracking of facility status with automatic identification of
> routes and trips affected by facility closures, fires, elevator
> failures, and so on; and
>
> Travel/arrival time prediction that is accurate to within one minute
> or 20 percent of the time remaining until arrival.

State-of-the-art deployment examples of Transportation Operations
Systems include:

> Los Angeles County Metropolitan Transportation Authority, Los Angeles,
> CA
>
> Features include:
>
> 2,400 buses dispatched;
>
> Video recording and transmission; and
>
> Archived running time data fed to the Scheduling Department.
>
> New Jersey Transit Rail Operations, Newark, NJ
>
> Features include:
>
> Nine rail lines dispatched;
>
> 477 route miles, 91 controlled interlockings, and 1,222 signals;
>
> Real-time data exchange with Amtrak for train tracking on the
> Northeast Corridor;
>
> Power dispatching;
>
> Reduced dispatcher workload through support for stacked routes (series
> of intended routings for next few trains, pre-programmed by the
> dispatcher and executed automatically in sequence by the train control
> system as successive trains pass by);
>
> Remote surveillance and control of movable bridges;
>
> Integrated passenger information output (train control system
> automatically generates status and arrival information for every train
> at every station);
>
> Integrated event playback; and
>
> Integrated training environment.

### 3.5.3 Emerging Trends {#emerging-trends-6 .Style-Heading-3-+-Justified}

#### 3.5.3.1 Modularization {#modularization .Style-Heading-4-+-Justified}

The move from proprietary communications protocols toward open
communications standards such as APCO-25 is bringing the transit
industry closer to the goals of interagency interoperability,
incremental system renewal, and incremental system expansion without
feeling "locked in" to a specific vendor. Decoupling the communications
protocol from the AVL/CAD application will make it possible to implement
open standards for vehicle-control center data exchange, allowing
agencies to easily upgrade or replace their AVL, MDT, and CAD technology
on a vehicle-by-vehicle, fleet-by-fleet, garage-by-garage, or
center-by-center basis as opposed to an "all or nothing" approach.

This decoupling of communications from AVL/CAD will also make it
possible for agencies to implement different communications solutions
optimized for individual modes, providers, and service areas while
maintaining consistency in AVL/CAD operation.

All of this, however, comes at a cost. General purpose communications
standards, when used in bandwidth-constrained transit-specific
applications, are expected to offer less than 50 percent of the
information throughput available from proprietary solutions that have
been specifically optimized for the transit environment. One method for
limiting bandwidth usage that is gaining popularity as vehicles become
"smarter" is to not "poll" the vehicles, but rather have the vehicle
monitor its own route and schedule adherence and then transmit exception
reports only. Such implementations conserve bandwidth even further by
having the vehicles transmit their status less frequently the further
they are from a scheduled stop.

#### 3.5.3.2 Remote Vehicle Disable {#remote-vehicle-disable .Style-Heading-4-+-Justified}

The nation's Homeland Security Department is beginning to call for
transit agencies to have the ability to remotely disable stolen transit
vehicles. In response, some vendors have begun to offer this capability.
The capability is still very much in its infancy, however. Reliability
has not yet been proven and the potential does exist for unintended
activation of the disable feature at inopportune times (due to
electromagnetic interference, component malfunction, or deliberate
attack).

### 3.5.4 Challenges and Lessons Learned: General Transportation Operations Systems {#challenges-and-lessons-learned-general-transportation-operations-systems .Style-Heading-3-+-Justified}

Transportation Operations Systems were the earliest of the ITS fleet
management technologies to be widely deployed, so it is perhaps not
surprising that it is in this area that the bulk of the industry's
lessons learned knowledge can be found.

The ever-present challenges of system cost, quantity of data produced,
and acceptance by operators, though still of concern, have already been
discussed at length in previous state-of-the-art reports and are not
specifically addressed in this update. Many new items, however, are
addressed below.

#### 3.5.4.1 Specifications  {#specifications .Style-Heading-4-+-Justified}

Concerning specifications, most public transit procurement documents,
including some cited as "best practices," continue to follow a common
formula that combines background, technical specifications, project
management, proposal requirements, and other items into an interlaced,
multithreaded document that is often circumspect and difficult to
follow. These specification documents often state that the agency
desires to procure an "Advanced Public Transit Management System" or
something similar, but rarely succinctly define exactly what they mean
by the term. Nor do agencies define in certain terms what they need to
be able to get out of the system or the performance and behavior
required under definable conditions of specific local interest. Agencies
typically provide a great deal of technical design detail, but often
neglect the business requirements that define the true basis for
acceptance of the delivered system. Lacking this basic element,
specifications often leave open the possibility that the delivered
system will "meet the specification" yet will not fully provide the
business tools or results the agency originally intended.

In this regard, the state of the art in ITS fleet management system
specification and procurement, as currently practiced, is lacking. To
the extent that procurement specifications include technical design
detail, vendors are restricted in their ability to offer more
cost-effective solutions, and agencies put themselves at risk for the
quality of the end result. To the extent that specifications neglect
high-level business requirements and acceptance test scenarios, vendors
are denied critical knowledge of the agency's real needs. Moreover,
agencies open themselves to misinterpretation of requirements, which
severely limits their ability to hold vendors contractually accountable
for the functionality, performance, and usability of the delivered
system. Some of the lessons learned from agencies include:

> Start with the point; define the result that you need (i.e., business
> requirements) up front;
>
> Write for the vendor audience. Tell them what they need to know and
> the order in which they need to know it. Limit needless background,
> and avoid technical or procedural detail that can just as easily be
> proposed by the vendor or negotiated after vendor selection;
>
> Keep the specification organized. Group items such as agency
> background, vendor qualifications and proposal requirements in
> separate appendices where they can be easily identified, rather than
> spreading them throughout the technical specification. Keep design
> constraints (if any are really necessary) separate from business
> requirements; and
>
> Know your priorities and make them clear. Distinguish between truly
> "required" and merely "desired" features, capabilities, and
> characteristics.

A good specification is one that can also serve as an acceptance test
procedure. Agency leaders most likely care a great deal more that a
system will allow their staff to perform certain critical business tasks
with a given level of reliability and fault tolerance than they do about
what kind of technology the system runs on. These business-level
expectations form the true basis for final acceptance of the delivered
system, and should be specified in detail.

Therefore, procurement specifications should be constructed to clearly
and distinctly specify the acceptance criteria for the end product or
service in business terms. The FTA Best Practices Procurement Manual
(BPPM) refers to this advanced type of specification as a "performance
specification" (as opposed to a "design specification").[^57] A sample
specification format designed specifically to facilitate this kind of
advanced procurement vehicle is provided below.

Agencies will note that it is only in defining how the agency will
actually test the delivered system for final acceptance that the true
business (i.e., mission) requirements become completely and
unambiguously known. Taking the effort to do this up front often
requires additional time in specification development, but pays great
dividends throughout the remainder of the project in terms of improved
quality, improved vendor relations, improved quality of schedule and
budget estimates, and reduction of costly rework.

Agencies will also note that one does not need to be an ITS technology
expert to write a good fleet management performance specification. In
fact, due to the natural tendency for technical people to "cut to the
chase" by jumping straight to their vision of a design specification,
the more technical knowledge the author has, the harder it often becomes
to exercise the discipline required to focus first on those critical
business requirements that form the true basis for acceptance testing
and for determining the ultimate success or failure of the project.

One potentially useful resource for peer-reviewed samples of
state-of-the-art business- level performance specifications that are
testable and technology-independent are the "open source standards"
pages of the Transit Standards Consortium website at
[www.tsconsortium.org](http://www.tsconsortium.org/), currently under
development. Another useful source is the ITS performance specifications
(termed "*p_specs"*) sections of the USDOT National ITS Architecture Web
site.[^58]

A sample performance-based specification template that agencies might
find useful is included in this report as Appendix D.

#### 3.5.4.2 Testing  {#testing .Style-Heading-4-+-Justified}

Final acceptance testing of delivered computer systems throughout the
U.S. has been found to be generally inadequate. For an agency to know
that the delivered system actually performs as expected, the system
needs to be explicitly tested against each and every business
requirement found in the final contract specification.

The key to developing a comprehensive system test is to identify the
special cases and boundary conditions that may be important to the
agency and specifically verify the delivered system's behavior in the
field against each and every one prior to system acceptance. Test
scenarios (taken from real-world failures) for which agencies would
specify and verify desired system behavior might include:

> Receiving a new schedule while current schedule still in effect;
>
> Change from standard to daylight time while vehicles are still
> operating from previous day (if schedule runs that late);
>
> Loss of network connectivity to a tower site;
>
> Loss of network connectivity to a garage site;
>
> Loss of power at a garage site;
>
> Loss of wireless LAN at a garage site;
>
> Loss of communications with a dispatch center;
>
> Loss of communications with a vehicle;
>
> Restoration of previously lost communications;
>
> Extensive vehicle movement without logon;
>
> Planned connections/transfers;
>
> Dispatcher assigned to 2 or more non contiguous (geographically
> separated) routes or territories;
>
> Calls in queue exceed display space on screen;
>
> Vehicle short-turned or reassigned to new route or trip in mid block;
>
> Driver logon with good communications;
>
> Driver logon with communications failure;
>
> Driver logoff with communications failure;
>
> Emergency alarm;
>
> Locally reflected GPS signal (generating incorrect position
> indication);
>
> Temporary loss of GPS;
>
> Prolonged loss of GPS;
>
> Loss of vehicle odometer;
>
> Replacement of onboard computer;
>
> Failure of APC component;
>
> Update of onboard software;
>
> Repeated interruption of vehicle power during wireless data transfer;
>
> Repeated interruption of vehicle power during onboard system
> initialization;
>
> Repeated interruption of vehicle power during system shutdown;
>
> Loss of radio communications at a tower site; and
>
> Vehicle transition from one tower site to another.

#### 3.5.4.3 Vehicle Installations  {#vehicle-installations .Style-Heading-4-+-Justified}

Successful agencies have learned to include requirements for a detailed
vehicle survey, installation plan, installation walkthrough, and
prototype installation for each distinct vehicle make and model to be
equipped. Many also require site-specific training of installation
personnel.

#### 3.5.4.4 Test Bench {#test-bench .Style-Heading-4-+-Justified}

Some agencies often include at least one vehicle equipment test bench
(possibly as many as one per garage, depending on the system maintenance
strategy to be employed) in their list of deliverables. The test bench
typically includes all harnesses, connectors, power supplies, equipment,
and components found onboard a vehicle, together with whatever emulators
might be required to fully test a complete vehicle equipment suite in a
simulated onboard environment. Such test benches have been found useful
for factory testing, and as a valuable tool for ongoing system
maintenance, failure isolation, and troubleshooting. It should be
delivered to the agency prior to prototype vehicle installation.

#### 3.5.4.5 Custom Development {#custom-development .Style-Heading-4-+-Justified}

Agencies often insist that vendors customize their systems to provide
capabilities beyond those included in the off-the-shelf product.
Sometimes this results in an enhanced product for which the vendor
believes there to be a larger market. In this case, the vendor adds the
new feature to its product line and provides support for routine
upgrades and bug fixes accordingly.

More often, however, unless adoption into the standard product line
(i.e., "productization") is specifically required by the contract, this
results in a custom application for which the agency is the only
customer.

In this later case, agencies need to recognize that they have just
created an application that the vendor cannot support in the way the
agency might assume or expect. All costs for upgrades, debugging
repairs, migration to new versions of third party operating systems and
databases, and so forth must be passed on to this one agency. They
cannot be spread over a larger customer base because that larger base
simply does not exist.

Moreover, agencies that insist on directing a vendor to develop and
install custom applications against the vendor's better judgement should
be prepared to accept liability and indemnify vendors for failure or
misuse in the field. A prime example in this area would be the ability
to remotely disable a vehicle. An agency that requires this feature of a
vendor that has deliberately chosen not to offer it as part of their
stock product should be prepared to accept liability for that decision.

#### 3.5.4.6 Achievable Scope {#achievable-scope .Style-Heading-4-+-Justified}

Agencies successful in delivering projects that are complete, on time,
and within budget have learned to "settle" first for a vendor's proven
off-the-shelf offering, and then only later (after delivery and
acceptance of the baseline implementation) have the vendor implement
enhancements to the system to provide additional desired features or
performance by adding narrowly defined incremental advances to the
off-the-shelf product. A project that overreaches or overpromises is one
that is doomed to failure and frustration for all involved.

#### 3.5.4.7 Test Environment {#test-environment .Style-Heading-4-+-Justified}

Agencies often forget that they will need a separate, on-site parallel
test environment in which to verify future enhancements or upgrades to
the delivered system (and its related third-party report tools,
communications, database management systems, drivers, administrative
tools, and operating systems) after initial acceptance. The test
environment should be procured concurrently with the production system,
and may be configured to additionally serve as a training platform for
new operators and administrators.

#### 3.5.4.8 Ownership of Data  {#ownership-of-data .Style-Heading-4-+-Justified}

At least one agency has recently found itself in a relationship with a
system vendor who has asserted ownership of the passenger information
output of the operations control system. In order to disseminate this
information to passengers, the agency must pay license fees on a
per-stop basis. Agencies should carefully review proposed agreements for
this sort of language, and should specifically require that any and all
data (other than the actual operating software itself) collected by,
resident in, or output from the operations control system is theirs to
use, modify, and disseminate as they see fit.

#### 3.5.4.9 Operational Flexibility {#operational-flexibility .Style-Heading-4-+-Justified}

The design and provisioning of the transit service itself can easily
limit the ultimate utility of even the most advanced operations systems.
Adequate recovery time, gap buses, rescue vehicles, field supervision,
operator training, and maintenance support must still be available if
operators are to make the most of the new capabilities these advanced
systems can provide.

#### 3.5.4.10 Project Planning and Project Management {#project-planning-and-project-management .Style-Heading-4-+-Justified}

##### 3.5.4.10.1 Comprehensive Technology Plan  {#comprehensive-technology-plan .Style-Heading-5-+-Justified}

Agencies that have embarked on fleet management system projects without
first, or concurrently, developing a comprehensive technology plan have
found that the practice leads to a flawed implementation and a poor APTS
initiative. Agencies should explicitly specify integrated technology
planning as part of the project when applying for federal grants so as
not to be restricted in their use of federal funding for this critical

element of system engineering analysis.

##### 3.5.4.10.2 Risk Management {#risk-management .Style-Heading-5-+-Justified}

Agencies should allow time in the project plan for resolution of
third-party risks (e.g., delays in obtaining FCC licenses, zoning for
towers, DOT approval of dash-mounted equipment, availability of third
party data, etc.). Agencies should also require vendors to submit lists
of uncertain items in their proposals. It is recommended that agencies
develop contingency plans for risk response, then allow time and budget
for contingency plan execution (e.g., for redesign, contract extension,
etc.) in the event that these risks actually materialize.

##### 3.5.4.10.3 Dedicated Project Manager {#dedicated-project-manager .Style-Heading-5-+-Justified}

Just as vendors need to have a project manager (PM) who is always
available to the customer, it is recommended that agencies have a
project manager with project management (i.e., decision making)
authority who is always available to the supplier. Experience indicates
that agencies should assign a dedicated full-time project manager to any
project expected to consume over \$200K per month. Agencies should
additionally assign a deputy PM to projects expected to spend over \$1M
per month to ensure on-time delivery and continuity of control.

##### 3.5.4.10.4 ITS Architecture Policy Compliance  {#its-architecture-policy-compliance .Style-Heading-5-+-Justified}

The FTA Policy on ITS architecture consistency is far less a technical
requirement than a procedural one. Central to ITS architecture
consistency is the requirement for an "ITS System Engineering Analysis."
Consisting of a sound system engineering and project development
practice, the FTA Policy is designed to ensure a high probability of
project success, and is looked on by project management professionals
more as a helpful checklist than as a burdensome federal regulation.
This procedural requirement is intended to ensure (and requires
documentation of) appropriate stakeholder consensus, value engineering,
and requirements analysis, and is a direct project manager
responsibility. Agencies that assume the system engineering analysis to
be a mere technical detail and fail to adequately train their project
management personnel to perform them risk noncompliance and loss of
federal funding for their ITS programs.

#### 3.5.4.11 Procurement  {#procurement .Style-Heading-4-+-Justified}

##### 3.5.4.11.1 Value Engineering {#value-engineering .Style-Heading-5-+-Justified}

Relatively unimportant "casual" specification items included in the
procurement document often drive up cost. Agencies should take advantage
of pre-proposal conferences to discuss cost drivers with prospective
vendors, and reissue specifications accordingly. They may also want to
revisit the issue again during proposal evaluation when they can issue
revised specifications and request revised proposals from short-listed
firms prior to vendor selection. Inclusion of 200-300 hours for detailed
value engineering consultation following contract award has also been
found to be helpful.

##### 3.5.4.11.2 Canned Specifications {#canned-specifications .Style-Heading-5-+-Justified}

Rather than settle for a modified copy of a specification originally
created for someone else, agencies should make the effort to identify
actual needs for their own specific environment. Otherwise, agencies
risk buying and incurring additional operating and support costs for
items that they do not actually need, and also risk missing some of the
more important items.

##### 3.5.4.11.3 Quality of Proposals {#quality-of-proposals .Style-Heading-5-+-Justified}

Successful agencies have learned to fight the urge to hide the budget
when advertising a request for proposals (RFP) or invitation for bids
(IFB). Vendors' profit margins are self-regulating in a competitive
procurement environment; knowledge of the project budget will only allow
prospective suppliers to develop more reasonable proposals that more
closely address the agency's actual intent.

##### 3.5.4.11.4 Procuring for Best Achievable Value  {#procuring-for-best-achievable-value .Style-Heading-5-+-Justified}

Current competitive procurement provisions in Federal Acquisition
Regulations (FARs) are sub-optimized to deliver either best quality or
lowest purchase price, but not necessarily the best value (quality per
dollar). Following are suggestions for obtaining best value on a
federally funded project without violating the FARs.

The IFB process is not recommended for ITS procurements. However, it can
be made to work if needed. In procuring for best value under either a
one-step (i.e., low price) or two-step Brooks Act (i.e., best quality)
IFB process, the key is to pre-qualify vendors through live
demonstration prior to bid acceptance, to evaluate bids based on total
net cost rather than just initial purchase price, and to be able to
place a reasonably defensible monetary value on just how much a given
"desired" system characteristic is worth to the agency.

Total cost is initial purchase price plus five to seven years' worth of
maintenance and software support (which can be solicited as an option,
whether the agency actually intends to contract it out or not), plus
agency support and project management over the duration of the project
(which can be calculated in terms of some representative number of
dollars per month based on history).

The offsetting value of any "desired" items that a proposer commits to
deliver is represented in the bid evaluation process as a credit that
serves to reduce the total net cost to the agency. In this way, the
agency can award to a vendor that offers the best total value, not just
the lowest initial purchase price.

The RFP process is preferred for ITS procurements. In procuring for best
achievable value under a RFP process, the key is to weight the
evaluation heavily in favor of the off-the-shelf offering that satisfies
the greatest number of your most important "required" specification
items at the lowest total cost. Following deployment and acceptance of
the selected off-the-shelf product, further enhancements can then be
developed and deployed at a later time as long as the budget allows.

The RFP should ask for proposals in a minimum of two sections. The first
is a base proposal for off-the-shelf "in-stock" functionality only,
noting specifically any exceptions where specified "required" or
"desired" functionality will not be met. The second section is an option
for upgrading the off-the-shelf product to provide the full range of any
remaining functionality and features described in the technical
specifications. This second section should be delivered as a series of
options that would allow the agency and the vendor to work together to
value engineer the most cost-effective solution. It is also possible to
specifically request an intermediate proposal identifying costs (if any)
for upgrading the off-the-shelf offering only to the point where it
could meet some minimum functionality level (the truly "must haves")
defined by the agency.

The off-the-shelf version will likely be a highly capable,
tightly-integrated unit that gives the agency most of what it is looking
for, but with proprietary interfaces that lock it into a single vendor
for maintenance, upgrades, and expansions. The smaller the ultimate
scope of deployment, the shorter the expected lifespan of the system,
the more confidence the agency has in the vendor, and less likely the
prospect of future enhancement or expansion, the less objectionable
these tradeoffs become. If an agency finds that it can live with the
off-the-shelf version, or with some minimum intermediate feature set,
either as an end product in itself or as a starting place for subsequent
customization following initial delivery and test, it may be able to
save 30 -50 percent (or more) off the cost of the system by sticking
with an off-the-shelf product rather than forcing a vendor to develop
something new practically from scratch.

"Total cost" in the RFP process, as for the IFB, is initial purchase
price, plus 5-7 years' worth of maintenance and software support, plus
the cost of agency support and project management over the duration of
the project.

Both the National Transit Institute and the National Highway Institute
offer valuable courses in ITS procurement.

#### 3.5.4.12 Standards {#standards .Style-Heading-4-+-Justified}

##### 3.5.4.12.1 Use of Standards {#use-of-standards .Style-Heading-5-+-Justified}

Best practices for use of standards have yet to be formalized. Thus,
agencies are cautioned to avoid simply specifying "compliance" to a
standard or "consistency" to an architecture.

It is too easy for a vendor to "comply" with a standard, yet not provide
the multivendor interchangeability the agency thought it was getting.
Given the current state of standards implementation, if agencies desire
a specific modular architecture, then they need to define the specific
interfaces they care about and spell out their behavior in detail.

Alternatively, agencies may allow the integrator to define it for them,
but then must require that they receive the interface control documents
as deliverables with full rights for royalty-free distribution and
reuse.

At a minimum, agencies should require detailed interface specifications
for all flows defined in the Regional ITS architecture, sufficient to
allow qualified third-party suppliers to provide interoperating modules
without the need for further vendor assistance.

One potentially useful resource for peer-reviewed samples of
specifications for use of national standards in ITS procurement is the
"open source standards" pages of the Transit Standards Consortium Web
site, currently under development at
[www.tsconsortium.org](http://www.tsconsortium.org/).

##### 3.5.4.12.2 Transit Communications Interface Profiles (TCIP)  {#transit-communications-interface-profiles-tcip .Style-Heading-5-+-Justified}

While some question the recent federally sponsored TCIP Dialog
development effort (TCIP 2.X), the original TCIP data dictionary (NTCIP
1400 - 1408) remains a valuable resource. Standard interfaces based on
the TCIP data dictionary have been successfully implemented by the
Southern California Association of Governments, New York State DOT, and
others. The NTCIP 1400 series documents are well suited for facilitation
of interface designs involving flat file transfer via XML (a common
language for data representation), and provide a solid basis for
standardization of intra-agency and interagency data exchange. As of
this writing, they are electronically available free of charge in an
easy to use Microsoft Access database format, from the Institute of
Transportation Engineers at [www.ITE.org](http://www.ITE.org/).

##### 3.5.4.12.3 J1708 Compliance {#j1708-compliance .Style-Heading-5-+-Justified}

SAE J1708 and its commonly associated sister standards (or virtually any
network standards currently in use) provide for locally defined codes
and a "data link escape" message that makes it possible for a vendor to
be "compliant" with the standard while nonetheless implementing a
proprietary system architecture that denies the user the multivendor
interoperability and interchangeability they thought they were
specifying when they required use of the standard. The addition of the
phrase "without use of the data link escape message or any
vendor-defined MIDs or PIDs, except when using the J1708 network to
accomplish software upload and file transfer operations not directly
supported by SAE-J1587" to any specification requiring "J1708
compliance" should go a long way toward removing this ambiguity. Also,
agencies have learned to explicitly specify SAE-J1587 as the message
standard to be used with the J1708 transport protocol, and to include a
complete description of the request-response behavior required of each
distinct component on the network.

## 3.6 Lessons Learned: Rail Operations Control Systems {#lessons-learned-rail-operations-control-systems .Style-Heading-2-+-Justified}

### 3.6.1 Dark Territory {#dark-territory .Style-Heading-3-+-Justified}

While a train control system would appear to provide the ultimate
controlled environment for vehicle location and passenger information,
it does have its limitations. Train control systems have traditionally
relied on track circuit occupancy to follow the location of trains
across the network. While this works well for trains in a "controlled
territory," there are many areas on a railroad --- especially yards and
terminals, and even portions of lines that may be controlled (i.e.,
dispatched) by other railroads --- that may not be visible to the
agency's train control system. For these areas that are "dark" to the
agency's train control system, GPS can provide an invaluable supplement
to conventional track circuit-based train location.

### 3.6.2 Train ID {#train-id .Style-Heading-3-+-Justified}

Train control and signal systems are very good at keeping trains safe by
preventing routings and movements that could lead one train to move onto
a track that is already, or will soon be, occupied by another. *Which*
train is immaterial, all that really matters to the train control system
is that *some* train is occupying the track. The dispatchers need to
know which trains are which, but the system does not. As soon as the
train control system is used for fleet management, performance
measurement, and passenger information, however, then electronic
knowledge of vehicle identification and train assignment (i.e., exactly
which vehicle is present at a given location and which scheduled trip it
is currently operating) becomes critical.

A problem common to many train control systems is that this critical
information may not be known (electronically) in a timely manner. Often,
depending on dispatcher workload, trains may travel for some miles
before they are positively identified to the system. Related passenger
information generated by the system during these periods will be of
questionable quality at best.

The most advanced train control systems ensure quality and consistency
by automatically comparing train identification data entered onboard by
the train crew with that proposed by the train control system (usually
based on schedule) when the train passes a dynamic tag reader or GPS
reporting point when first appearing in controlled territory. The
dispatcher is thereby relieved of much of the burden of train ID
verification, resolving only those cases where the system and the crew's
input disagree, and train identification becomes automatically known to
the system in a far more timely and reliable manner.

## 3.7 Lessons Learned: Bus Operations Systems {#lessons-learned-bus-operations-systems .Style-Heading-2-+-Justified}

### 3.7.1 Designing for Modular System Upgrade and Expansion  {#designing-for-modular-system-upgrade-and-expansion .Style-Heading-3-+-Justified}

The key to modular system upgrade and expansion is a tiered modular
architecture with provisions for distributed parallel processing (for
scalability) and well-defined standards for critical system interfaces
(for modularity). At a minimum, the following interfaces should be fully
standardized with no allowance for vendor-specific codes or formats:

> Interfaces between in-vehicle subsystems (typically over a SAE J1708
> network). Example: Interfaces between data terminal, vehicle locator,
> odometer, vehicle identification unit, fare register, fare card
> reader, destination signs, event recorder, powertrain, passenger count
> processors, and so on.
>
> Interfaces between in-vehicle and vehicle base components (typically
> over an IEEE 802.11 wireless LAN). Example: Interfaces between fare
> register and garage computer, between event recorder and garage
> server, and between destination sign controller and garage server.
>
> Interfaces between vehicle base components and central processing
> facility (typically over an IP network). Example: Interfaces between
> garage server and enterprise data warehouse.

Ultimately, the interfaces between CAD and radio, and between radio and
AVL, may one day also be standardized, which will effectively decouple
the in-vehicle and fixed base components of the CAD/AVL system. While
there is no question that the idea of complete independence from any one
system vendor has broad appeal in principle, it is still an open
question as to whether this is truly necessary or even desirable in the
real world. The question is currently an academic one in any event, as
the present state of the art does not yet provide this final level of
CAD/AVL modularity.

### 3.7.2 Communications {#communications-1 .Style-Heading-3-+-Justified}

On average, commercial wireless providers (i.e., cellular) would appear
to have adequate capacity to handle transit applications in a reliable
and timely manner. However, incidents and emergencies can occur at the
local level. The additional wireless traffic induced by these local
incidents may quickly flood individual cell sites where the agency needs
communications the most. To guarantee availability, most agencies
currently still opt to operate their own private wireless network, even
in locations where it might appear on the surface that commercial
services may be more favorably priced. This situation may soon be
changing, however, with the trend toward greater reliance on data rather
than voice communications, which is far less bandwidth intensive.

## 3.8 Lessons Learned: Paratransit Operations Systems {#lessons-learned-paratransit-operations-systems .Style-Heading-2-+-Justified}

### 3.8.1 Multiple Providers {#multiple-providers .Style-Heading-3-+-Justified}

Paratransit operations typically involve a number of small contracted
service providers. The individual providers are usually too small to
need, or afford, a modern fleet management system, yet together they may
comprise a sizable fleet that the agency needs to be able to manage
effectively. Taking advantage of the economies of scale available to a
regional coordinating body, state-of-the-art paratransit operators have
often opted to supply their providers with the necessary communications,
dispatch, electronic maintenance, and administrative services free of
charge.

### 3.8.2 Verification of Service Delivery {#verification-of-service-delivery .Style-Heading-3-+-Justified}

Paratransit operators have learned the hard way that fraud, typically in
the form of inflated ridership figures or trips billed but never made,
is too often an everyday part of life. State-of-the-art operators have
developed independent cross-checks, often through integration of vehicle
location with an electronic fare collection system, to verify reported
ridership, billed trips, and service performance.

## 3.9 Lessons Learned: Other Operations Systems {#lessons-learned-other-operations-systems .Style-Heading-2-+-Justified}

### 3.9.1 Elevator and Escalator Status  {#elevator-and-escalator-status .Style-Heading-3-+-Justified}

Modern SCADA (Supervisory Control And Data Acquisition) systems can
automatically collect all manner of operating and maintenance data from
elevators, escalators, climate control, public address, ventilation, and
electrical distribution systems. In addition to notifying operators of
specific platforms affected by failed equipment, this information
(especially escalator and elevator status) can be automatically made
available to disabled customers considering travel to an affected
station. The time for a customer to find out that the elevator is out of
service is not just after the train has left that customer on the
platform.

### 3.9.2 Crowd Control {#crowd-control .Style-Heading-3-+-Justified}

Especially in times of service delays or disruptions, platforms can
become unusually crowded, sometimes dangerously so. Agencies that have
implemented widespread video surveillance of station platforms have
found digital video technology invaluable for identifying and managing
potential crowd control problems.

## 3.10 References {#references-1 .Style-Heading-2-+-Justified}

National Intelligent Transportation System Architecture User Service
2.1, Public Transportation Management, US Department of Transportation,
Washington, DC, 2005.

<http://itsarch.iteris.com/itsarch/html/user/usr21.htm>.

National Intelligent Transportation System Architecture User Service
4.4, Commercial Vehicle Administrative Processes, US Department of
Transportation, Washington, DC, 2005.

<http://itsarch.iteris.com/itsarch/html/user/usr44.htm>.

Intelligent Transportation Systems Technology Overview, US Department of
Transportation, ITS Joint Program Office, Washington, DC, 2005.
<http://itsdeployment2.ed.ornl.gov/technology_overview>.

Furth, Peter G., "Uses of Archived AVL-APC Data to Improve Transit\
Performance and Management: Review and Potential," Transit Cooperative\
Research Program, Washington, DC (2003).  TCRP Web Document 23.\
<http://gulliver.trb.org/publications/tcrp/tcrp_webdoc_23.pdf>.

Mitretek, "Transit Operations Decision Support Systems, Core Functional
Requirements for Identification of Service Disruptions and Provision of
Service Restoration Options." April 3, 2003.
[www.fta.dot.gov/whats_new/12174_15078_ENG_HTML.htm](http://www.fta.dot.gov/whats_new/12174_15078_ENG_HTML.htm).

Smith, H., Hemily, B., Ivanovic, M., "Transit Signal Priority (TSP): A
Planning and Implementation Handbook" ITS America, Washington, DC, May
2005.

# Chapter 4 Electronic Fare Payment

## 4.1 Introduction and Technology Overview  {#introduction-and-technology-overview-1 .Style-Heading-2-+-Justified}

Electronic fare payment provides an automated means of collecting and
processing fares for public transportation services such as bus, rail,
ferry, and other modes. Public transportation users can select from a
variety of fare products, such as magnetic stripe cards (read-only or
read-write), smart cards with varying levels of memory and computing
power, or credit cards to pay for transportation services. The
description of electronic fare payment in this report is organized into
three major categories:

> Fare Systems
>
> Fare Products (Media)
>
> Clearinghouse/Regional Service Center (CH/RSC)

These categories have been structured to correspond with the significant
work undertaken by the Universal Transit Farecard Standards (UTFS)
Program being funded by the United States Department of Transportation
(USDOT) and coordinated by the American Public Transportation
Association (APTA). As discussed in Section 2.6, the UTFS program seeks
to develop standards, specifications, and guidelines for electronic fare
payment systems throughout North America.

Although this report discusses fare systems, fare products, and the
Clearinghouse in different sections, all three elements need to work
together in a transit electronic fare payment system. The section on the
Clearinghouse/Regional Service Center highlights the importance of
integration when deploying a regional fare system that involves multiple
agencies. In regional fare systems, integration can occur at a number of
levels to help facilitate seamless fare payment, including an integrated
approach to fare policies, fare media or card reading standards, fare
equipment, and revenue reconciliation.

In the last few years, steady progress has been made in the
implementation of automated fare collection systems and the development
of standards. In addition, the cost of sophisticated fare products, such
as smart cards, has decreased, thereby making the systems more
affordable to a wider range of public transit agencies. Like other ITS
areas, there has been a push for integration of transportation services
to support more seamless travel between modes, such as rail and bus, as
well as different regional transportation providers.

## 4.2 Fare Systems  {#fare-systems .Style-Heading-2-+-Justified}

### 4.2.1 Technology Description {#technology-description-8 .Style-Heading-3-+-Justified}

A fare system can be defined as the functions and equipment used by a
transit agency to deploy a fare collection system. These systems may be
closed systems, which are typically defined by an agency or region that
accepts fare media from only one issuer and only support transportation
services. In contrast, open systems accept fare products from multiple
issuers (such as credit cards). An agency's electronic fare payment
system may include components such as:

> Ticket vending machines (TVMs);
>
> Point of Sale (POS) terminals;
>
> eCommerce Web sites that sell fare products;
>
> Manned card issuance and revaluation networks;
>
> Fare gates and turnstiles;
>
> Card readers and validators;
>
> Depot and station computers;
>
> Customer service centers;
>
> Merchant sales outlets;
>
> Central computer systems; and
>
> Clearing and settlement functions to support revenue reconciliation
> and other fare data analyses.

![](media/image27.png){width="6.209722222222222in"
height="5.133333333333334in"}

[]{#__RefHeading___Toc129324158 .anchor}Figure 16 Fare Management System
Architecture

The fare system architecture shown in Figure 16 includes four distinct
levels:

> Level 1 represents the front-end device tier. These devices perform
> card reading and writing, and card issuer functions. The technologies
> are deployed on vehicles, at station turnstiles, and at other fare
> payment and sale points where patrons purchase fare media or present
> fare media to readers. Examples include ticket vending machines,
> balance enquiry machines, onboard driver consoles, card validators,
> fareboxes, and fare gates/turnstiles.
>
> Level 2 is the station or depot-level computer tier. At this level,
> fare transaction data are collected and aggregated from the field and
> vehicle devices. The data are then forwarded to the agency's central
> computer. Maintenance data, such as equipment availability, may also
> be forwarded. Data can flow in the other direction as well, such as
> hot lists or fare table changes from the central computer to the
> front-end devices.
>
> Level 3 represents the agency's central computer system that collects
> and processes the station- or depot-level computer data.
>
> Level 4 is the Clearinghouse and Regional Service Center tier where
> transactions are cleared and settled in multi-organization fare
> systems. Reporting and management functions for a multi-organization
> fare system also take place at this level. The functions performed at
> this level are governed by the business rules agreed to by all system
> participants.

Fare products such as cash, tickets, smart cards, magnetic stripe cards,
and other media are not shown in Figure 16, but are defined as Level 0.
Advanced networking capabilities and robust servers are critical
components of the infrastructure needed to support all levels of an
electronic fare payment system.

Electronic fare payment systems can provide a range of potential
benefits to transit agencies and their customers, including simplifying
fare payment, increasing customer convenience, reducing boarding times,
improving revenue security, increasing information about ridership and
fare payment trends, and potentially eliminating the acceptance of cash,
coins, and tokens. Contactless smart card readers can reduce maintenance
and equipment downtime due to the lack of moving parts associated with
solid-state electronics. Equipment reliability rates increase and there
is a potential for reduced maintenance costs (e.g., a contactless smart
card reader is less maintenance intensive than a mechanism to accept and
transport tickets).

Electronic transactions also facilitate data gathering and analysis
because of the additional fare and ridership information obtained
electronically (e.g., the time, location, and type of each transaction).
Analyses and reporting tools are needed to verify, format, and query
this information for it to be accessible and valuable to the transit
agency.

There are a number of newer and emerging technological changes and
integration options currently offered by suppliers that can accommodate
both open and closed fare systems. Examples include fare transaction
machines that can read and write to multiple media and fare products,
fare box add-ons that handle contact and contactless cards, and ticket
vending machines with bigger, more flexible screens and menus.
Electronic screens and menus can more easily present changing fare media
options than equipment dominated with fixed buttons. New fare products,
as described in Section 4.3, have also allowed new fare payment and
incentive options. In general, most fare technologies have been
available for several years, but the deployment of these technologies
has been relatively slow due to the length of time needed to plan, fund,
procure, implement, and test them.

Some interesting applications of fare technology are discussed below and
include:

> Multi-application smart cards (e.g., paying fares and gaining building
> access);
>
> Using fare technologies to simplify regional fare payment for both
> customers and riders;
>
> Partnering with private sector participants;
>
> Creating new marketing and incentive programs; and
>
> Emerging paratransit applications.

#### 4.2.1.1 Electronic Fare Collection Systems to Solve Complexity and Provide Integration {#electronic-fare-collection-systems-to-solve-complexity-and-provide-integration .Style-Heading-4-+-Justified}

Some of the newer options for electronic fare collection systems can
help simplify regional fare payment issues for travelers. Regional
travel issues have arisen because suburban sprawl and the diffusion of
employment sites have created more complex travel patterns across
transit service provider boundaries. New customer travel requirements
demand that integration of transit services be improved to better serve
these changing needs. Today's travelers move more often between
different service providers. They also move between different modes such
as bus, rail, and paratransit. In these chained trip situations fare
payment can be expensive, complex, and confusing.

In some areas where passengers use multiple transit operators and
different modes to complete their travel trips, transit operators are
moving away from multiple, nonintegrated fare collection systems to
systems that only require use of a single fare product. A common
progression is for a group of regional agencies to start with individual
agency fare products. The next move typically involves a regional
magnetic stripe fare product, followed by use of contactless smart cards
across the region. A common electronic fare collection infrastructure
can provide efficiencies to each of the various regional agencies and
help improve overall customer service.

#### 4.2.1.2 Smart Card-Based Fare Systems {#smart-card-based-fare-systems .Style-Heading-4-+-Justified}

Smart card based fare collection systems provide a good opportunity to
facilitate multimodal trip making, which can be complex. A smart card is
a more secure and flexible option than a magnetic stripe card because of
its embedded microprocessor and memory that allow more complex data
interactions with the read/write device and more secure encryption.
Smart cards can allow travelers to pay for multiple modes of
transportation regardless of whether the service is administered by one
agency or by multiple agencies within a region. In addition, the better
memory and the processing capabilities of a contactless or proximity
smart card-based system, the easier it is to incorporate other nonfare
applications such as employee credentialing, building access, or
accepting smart cards issued outside the regional transportation system
such as by a financial institution.

The level of integration in smart card fare systems that serve multiple
transportation agencies can vary greatly. The simplest level of
integration involves the use of a common card with fare payments
occurring solely from an "electronic purse."[^59] In this simple
integration model, agencies can have independent fare structures. At a
more complex level, fare structures and transfer policies may be
coordinated within the region. In this case a customer may use the same
fare card with different fare payment options to obtain transportation
services from a variety of operators and modes.

To effectively integrate fare payment systems with a single payment
device, consensus between service providers must be reached on a variety
of program levels such as deciding transfer policies, fare policy, card
features, revenue reconciliation, clearinghouse and customer service
requirements, and performance specifications for cards and readers.

Critical to the success of an integrated fare payment system is ensuring
that customers can easily add value to their smart card, which is often
referred to as reloading or recharging the card. When a customer reloads
their card they typically add funds to the electronic purse, and/or
purchase another fare payment option such as using the card as an
unlimited ride pass. A transit agency can increase the number of
locations and methods by which customers can reload their smart cards by
integrating their cards with other reload networks. In addition to
reloading cards at vending machines and customer service offices,
options for recharging include ATMs, "intelligent" public phones,
hand-held devices, the Internet, kiosks, onboard the vehicle, and at
fare gates/turnstiles.

#### 4.2.1.3 Facilitation of New Marketing and Incentive Options {#facilitation-of-new-marketing-and-incentive-options .Style-Heading-4-+-Justified}

Electronic fare collection system components, such as magnetic stripe
cards, smart cards, and better back office analysis and reporting
systems have enabled new marketing opportunities and ridership incentive
options. In addition to flat cash fares, a wider variety of other fare
pricing options are possible. Examples include unlimited ride cards for
a specified time period, employer subsidies, and bonus trips for
frequent riders.

#### 4.2.1.4 Systems with Non-Transportation Agency Partnerships {#systems-with-non-transportation-agency-partnerships .Style-Heading-4-+-Justified}

Public transportation smart card applications can benefit significantly
from partnering with private sector commercial applications or other
government agencies. For example, partnering with a bank, a credit card,
or a telecommunications company may result in sharing the development
costs of the smart card infrastructure. Multiple card applications also
increase the attractiveness of the card to the customer and help
increase market penetration.[^60] In Europe, for example, a common
electronic purse can be used by consumers to purchase goods at
participating shops or when using public phones. In another example,
some combined or "open system" smart card applications have chosen to
keep the commercial activity separate (sometimes in a second electronic
purse) from the transit application. In Finland, some smart cards
combine transportation applications with municipal applications such as
parking, libraries, and public swimming pools.

Advances in smart card and electronic fare payment system technology
make these partnerships possible. It must be noted, however, that many
of the issues that need to be resolved in a multi-application
environment are not technical, but are instead institutional and
operational in scope. These issues lie in the economics of the business
case and in the operating rules between the entities, and can be quite
complex and delicate matters to resolve. For instance, a key stumbling
block between the transportation and financial industries is the high
cost of transaction fees charged to a transit agency for accepting a
bank-issued card for payment of fares at a fare gate, a turnstile, or on
a bus. These fees are typically very high relative to the low value of
the transaction. Issues such as this must still be resolved even after
the technology barriers are removed in a multi-application environment.

#### 4.2.1.5 Paratransit Applications {#paratransit-applications .Style-Heading-4-+-Justified}

Electronic fare systems can be designed to support a range of
paratransit and human services transportation provider needs. The
payment of fares and the establishment of eligibility must be a simple
process for the paratransit passenger when boarding the vehicle.
However, requirements for billings and payments can get complicated. For
example, some customers may be eligible for a variety of services that
are funded by different organizations at different funding levels. These
customers may also take trips that are not eligible for full
reimbursement.

Given the complexities associated with eligibility and payments
processes, automation to support fare payment can often provide a range
of benefits that include increased speed of reservations, boardings, and
back office processing, as well as improved accountability, tracking,
and accuracy of the data. In general, the automated support for fare
payment in the paratransit arena is closely tied to the general
paratransit operations system software.

### 4.2.2 State of the Art {#state-of-the-art-9 .Style-Heading-3-+-Justified}

Electronic fare collection systems with state-of-the-art components and
features are being demonstrated and implemented across the U.S. Some of
the systems will be described here, in Section 4.3 on Fare Payment
Products, and in Section 4.4 on the Clearinghouse/Regional Service
Center.

#### 4.2.2.1 LACMTA {#lacmta .Style-Heading-4-+-Justified}

The Los Angeles County Metropolitan Transportation Authority (LACMTA)
continues to upgrade its fare collection system over time, including
implementing a universal electronic fare payment system for its bus and
rail systems. Currently, the agency offers a regional EZ transit pass
good for travel on Metro Bus, Metro Rail, and 20 additional
transportation carriers.

LACMTA is also in the process of implementing a multifunction
contactless smart card system. Approximately 10,000 LACMTA employees are
using identification badges that provide not only transit access via a
smart card interface, but also building access/security, logon for their
maintenance system, and vehicle logon for bus operators. Eleven regional
transit providers are currently using LACMTA's technical specification
as a regional standard, and have signed contracts to obtain similar
equipment. LACMTA is about to select a vendor to design, build, operate,
and maintain a regional clearinghouse.

Another innovative feature of the system is the single-point logon for
the bus operator, who will only need to log onto the farebox. The
farebox then passes on the appropriate information to related "smart
bus" system components such as Automated Passenger Counters (APC),
Computer Aided Dispatch/Automated Vehicle Location (AVL), and next-stop
annunciators. This feature makes the logon process easier for the
operator, saves time in starting the bus service, and improves logon
accuracy for a range of ITS onboard systems.

In 2005 LACMTA opened the Orange Line, the first bus rapid transit (BRT)
application that will use only a smart card for fares (i.e., no onboard
farebox for collection of cash). Rather than logging on to the
nonexistent farebox, the bus operator will log on to a SmartMDT (i.e.,
Mobile Data Terminal). The Orange Line will operate similar to a
proof-of-payment rail system. Currently, the system is operating only
with prepaid paper media. The agency issues Proof of Payment tickets
from Ticket Vending Machines (TVMs). When fully operational, TVMs will
be able to issue smart cards and load products to new and existing smart
cards. Paper tickets will continue to be available to the occasional
rider and for patrons who do not have smart cards. Passengers with cards
simply validate their cards at Stand Alone Validators (SAVs) to enter
the paid area of the station and board the bus. Fare inspectors will
validate cards using a Hand Held Validator (HHV). Combined sales data
and card usage data will provide LACMTA with important information
regarding travel demands in Los Angeles County.

#### 4.2.2.2 ORANGES {#oranges .Style-Heading-4-+-Justified}

The Orlando Regional Alliance for Next Generation Electronic Payment
Systems (ORANGES) completed a field operational test that became the
first transit fare collection project in the U.S. to combine multiple
payment applications (toll, transit, and parking) into a single,
non-cash, payment media. The ORANGES limited-scale field operational
test was a joint effort of the Central Florida Regional Transportation
Authority (LYNX), the Orlando-Orange County Expressway Authority, and
the City of Orlando, in conjunction with the Federal Transit
Administration (FTA) and private sector companies.

ORANGES demonstrated the use of a single smart card to pay for services
at selected locations of the Orlando-Orange County Expressway
Authority\'s toll road system, LYNX\'s fixed-route bus system, and
several of the City of Orlando\'s parking garages. The ORANGES card
carried cash in electronic form that was accepted at all three agencies,
stored toll account information, and contained the full range of prepaid
7-day and 30-day transit fare offerings. Each agency managed its program
independently with the settlement of funds between the organizations
occurring at a single clearing source. The demonstration project has
ended. An evaluation of the project was completed in 2004 by the US
DOT/Volpe National Transportation Systems Center.[^61]

#### 4.2.2.3 San Francisco Bay Area {#san-francisco-bay-area .Style-Heading-4-+-Justified}

In February 2002 the Metropolitan Transportation Commission (MTC) and
six San Francisco Bay Area transit agencies introduced the
TransLink[^62] regional fare payment system. The TransLink smart card
system continues to be implemented in the nine- county region with a
growing number of transit partners. The card will be used for payment on
all Bay Area buses, trains, light rail lines, and ferries. One of the
innovative aspects of the TransLink smart card is its capability to
provide card holders with "electronic coupons," which is part of an
incentive program designed to reward and promote ridership.

#### 4.2.2.4 Maryland's Mobility Cards {#marylands-mobility-cards .Style-Heading-4-+-Justified}

The Maryland Transit Administration's MTA Mobility program was the first
paratransit service provider in the U.S. to provide smart cards to its
customers. The smart cards serve as identification cards, and facilitate
the monitoring of customer eligibility, fare payments, and boardings.
The cards have helped the MTA to better evaluate and track on-time
performance, and have resulted in easier scheduling and increased
customer satisfaction. The logon process for operators has also been
simplified because they now use a contactless smart card for logging on
to the Mobile Data Terminal (MDT) on the paratransit vehicle.

MTA started a pilot Taxi Access[^63] project in 2004 for ambulatory
mobility-eligible patrons with a magnetic stripe card that resembles a
credit card and includes the card owner's photo. In the pilot project,
patrons can call for a taxi ride 24 hours a day with no prescheduling
with MTA. The card also simplifies the payment process for the mobility
patron and administrative staff.

#### 4.2.2.5 eCommerce and Online Stores for Fare Products {#ecommerce-and-online-stores-for-fare-products .Style-Heading-4-+-Justified}

Transit agencies are now taking advantage of eCommerce opportunities
such as online stores to sell fare products over the Internet and
enhance customer convenience. Customers can buy fare products using
their home or work computers without standing in line or traveling to a
sales location, sales opportunities are not limited by physical store or
outlet hours, and recordkeeping is improved. San Diego Metropolitan
Transit System, TriMet (Portland, OR), King County Metro Transit
(Seattle), and the Chicago Transit Authority (CTA) are a few examples of
transit agencies that sell passes, tickets, visitor passes, and other
fare-related products over the Internet. Agency policies and procedures
need to be developed for eCommerce applications, particularly to ensure
secure Web sites.

#### 4.2.2.6 Emerging Trends {#emerging-trends-7 .Style-Heading-4-+-Justified}

##### 4.2.2.6.1 San Diego Metropolitan Transit System (MTS) {#san-diego-metropolitan-transit-system-mts .Style-Heading-5-+-Justified}

In San Diego County, the Metropolitan Transit System (MTS) and the North
County Transit District are upgrading their fare systems. By using some
of the same contracts, the agencies are moving toward a contactless
smart card system for their buses, the San Diego Trolley, and the
Coaster Commuter Train. Passenger convenience is increased by
eliminating the need to buy new passes every month, by having a choice
in types of fare products to load onto their smart cards, and by
eliminating the need for different payment mechanisms for the various
transportation providers. The new systems also benefit transit agencies
by providing accurate and timely revenue and data. It is anticipated
that fare recovery will increase and the potential for fraud will
decrease. Smart card distribution and use will begin in 2006, with a
full rollout of the smart cards expected by late 2007.

As with the LAMTC example described above, the MTS fare system will also
feature a single point of signon for the bus operator. Tests of this
innovative feature have been completed, with implementation expected
late in 2005. In this application the bus operator logs into the fare
collection system and the pertinent information will be passed to the
Computer Aided Dispatch/Automated Vehicle Location (CAD/AVL) system via
a standard J1708 communications network connection from the farebox.

##### 4.2.2.6.2 Utah Transit Authority (UTA) {#utah-transit-authority-uta .Style-Heading-5-+-Justified}

The UTA is planning to upgrade its fare systems over the next few years
and will have a pilot project in 2006. UTA's vision for contactless fare
payment has several elements that include:[^64]

-   Integration and interoperability with the broader electronic
    payments world;

-   A "Smart Bus" communications system with a single logon and control
    of all electronic devices. It is intended to be an internally
    designed, non-proprietary system with an open architecture using
    off-the-shelf hardware and software;

-   Collecting GPS location data at boarding with the fare payment
    information;

-   UTA Fare Card with its own application that can also be licensed to
    third parties (e.g., universities, ski resorts, banks);

-   Broad distribution of limited-use cards for visitors and infrequent
    or cash riders; and

-   An incremental, phased, and collaborative approach.

The UTA is planning to begin its pilot project on its UTA Ski Service
using ISO 14443 compliant contactless readers on 40 ski service buses.
One of the benefits of the pilot project will be to improve UTA's fare
collection and revenue management for riders who previously flashed
their ski passes or resort employee ID cards to ride the bus. The
project is also intended to test payments via new contactless
MasterCard, Visa, and/or American Express cards with UTA serving as a
merchant.

In addition to the emergence of more multimodal and regional fare
systems that support bus and rail, innovative fare collection systems
are being planned for paratransit and rural transportation service
providers. Some emerging examples are included below.

##### 4.2.2.6.3 Northern Shenandoah Valley (NSV) Public Mobility Program {#northern-shenandoah-valley-nsv-public-mobility-program .Style-Heading-5-+-Justified}

The NSV Regional Commission Commuter Bus Smart Card Pilot project has
the following three goals:

> Demonstrate the interoperability of an electronic fare medium in a
> largely rural region, and among human service and public
> transportation providers;
>
> Demonstrate the impact of such fare medium in planning, operating, and
> administering mobility services for transportation-dependent
> individuals; and
>
> Document the value of an electronic fare medium in managing
> entitlements for constituents who are disabled, older, and
> economically disadvantaged. [^65]

The proposed pilot will be implemented with buses that provide daily
commuter services through the Regional Commission's Valley Commuter
Assistance Program. The public-private partnership will equip these
buses with AVL, mobile data terminals, and contactless smart card
functionality to track and verify each trip and individual trip segment.
The rationale for using a smart card is based on two critical customer
considerations:

> Incorporation of restrictions on the type and amount of consumer
> information that can be provided per the Federal Health Insurance
> Portability and Accountability Act (HIPAA).[^66] The card must have
> the necessary level of security to preserve protected personal and
> medical information; and
>
> Consumers who use the card must have physical or cognitive
> disabilities that limit their capacity to manipulate a card that
> requires either swiping through or insertion into a slot.

The key institutional requirements are divided into three categories:

> Client (rider) identification;
>
> Special needs driver notification; and
>
> Trip purpose and segment information.

The Mobile Data Computers will be supported by wireless communications
and will "read" consumer information from the smart card, including
"special needs" and emergency contact, and then display that information
for the driver.

Figure 17 includes a diagram from the NSV project description that shows
the smart card reader-coordination system interface.

![](media/image28.png){width="5.98125in" height="2.71875in"}

[]{#__RefHeading___Toc129324159 .anchor}Figure 17 Northern Shenandoah
Valley Smart Card Interface

##### 4.2.2.6.4 Capital Area Rural Transportation System (CARTS) {#capital-area-rural-transportation-system-carts .Style-Heading-5-+-Justified}

The Capital Area Rural Transportation System is planning to implement a
magnetic stripe RideCARTS card to support their rural transportation
system, which provides services for travelers in nine Texas counties
surrounding Austin, the state capital. The RideCARTS card will become
the single fare media that supports all passengers, whether their fare
is paid individually or by a third-party purchaser.

The intent of the card program is to combine data and fare collection
into one instrument and to streamline the accounting and collection for
both, while at the same time providing ease of use by its customers,
both individuals and institutional purchasers (i.e., human service
agencies, local governments, etc.). It will also serve as the platform
to facilitate paperless, personless reporting for the disparate data
needs of purchasers of service, thereby reducing labor-intensive data
extraction and paperwork for CARTS. Further, the goal is to promote a
seamless fare relationship with Capital Metro, the metropolitan transit
authority also headquartered in Austin, Texas.

The Ride CARTS card will have an electronic purse that can be reloaded
over the phone or Internet. For paratransit customers, the system is
intended to work in conjunction with a Web-based tool that facilitates
screening the eligibility of clients, planning trips, and managing trip
data. When a paratransit customer boards the vehicle, they will swipe
their card and the predetermined cost of the trip will be deducted from
their card's electronic purse.

The CARTS fare system will also be designed to accept the Lone Star Card
issued by the State of Texas as a Medicare-related electronic benefits
card. Users of the Lone Star Card will swipe their card when they get on
and off the transit vehicle to facilitate a behind-the-scenes fare
payment process (no value is deducted from the card). The data collected
as a result of the card use, such as arrival times and trip distances,
will significantly streamline the various reporting requirements.
Eventually the electronic purse on the card will make trip payments, but
this will require additional work by the Texas Department of
Transportation that is not within the scope of this project.

##### 4.2.2.6.5 Other {#other .Style-Heading-5-+-Justified}

As part of the Puget Sound Region smart card project, the Washington
State Ferry system with assistance from its vendor is developing a
mobile Fare Transaction Processor consisting of a portable hand-held
unit that will serve as a fare vending, fare loading, and fare
verification device.

There is also some exploration occurring in the area of using cell
phones to make small purchases called "micropayments." This form of
m-commerce, short for Mobile Commerce, involves commerce over wireless
devices that may be extended to transit payment applications. The
concept is being explored as a payment option that has the potential of
being less expensive than using a regular credit card with its high
transaction fees.

## 4.3 Fare Payment Products (Media)  {#fare-payment-products-media .Style-Heading-2-+-Justified}

### 4.3.1 Technology Description {#technology-description-9 .Style-Heading-3-+-Justified}

Magnetic stripe cards for electronic fare payment (read-only and
read/write) are still extensively used throughout the transit industry.
Credit cards are used to purchase fare media, but have not gained the
wide-scale acceptance of fare cards because of their high transaction
processing fees. Additionally, their format is not standard in the
transit industry and would require a massive retrofit of legacy systems
that have been using thin flexible magnetic stripe cards as well as
Edmondson magnetic tickets. Smart cards are slowly being implemented in
the U.S. as compared to the faster rate of acceptance in Europe and
Asia. Limited use smart cards are also starting to emerge in the U.S.
market. Because of the lead time necessary to thoroughly test and deploy
new electronic fare media, it is not unusual to have several types of
electronic fare media in use at the same time at a transit agency or in
a region. For example, if a transit agency is switching from a magnetic
stripe card to a smart card, it may take months to retrofit all buses
with the new fare equipment. As a result, some modes or routes may have
the new system while others continue to operate with the old system
until it is replaced.

The term "smart card" covers a range of cards that use different
standards and have different capabilities. Contactless smart card
technology relies on a secure microcontroller (or equivalent
intelligence), internal memory, and a tiny embedded antenna that
communicates with a reader, typically through a contactless radio
frequency (RF) interface. Most new cards (memory logic and integrated
circuit chip cards) are using the ISO 14443 standard, which is being
adapted to support limited-use smart tickets.[^67] Smart cards may also
be hybrid cards that have two chips and support both contactless and
contact uses, or combi-cards that allow one chip to be accessed by
either a contact or contactless interface. Additionally, some cards are
emerging that support both magnetic stripe and smart card functionality.
A good starting point for obtaining additional information about smart
cards is at the Smart Card Alliance's Web site at
[www.smartcardalliance.org](http://www.smartcard.org/).

Some of the new, innovative smart card applications support
multi-applications such as different fare types and structures,
different agencies, different modes, and other activities such as
parking, building access, security, identification, and logon functions.

### 4.3.2 Changing Environment {#changing-environment .Style-Heading-3-+-Justified}

Unlike Europe and Asia, credit card issuers and the retail sector in the
U.S. have traditionally been slower to adopt smart card technologies.
The environment here, however, is finally starting to show some
significant changes, especially with respect to possible transportation
partnerships with bank card issuers, credit card issuers, retail
merchants, and vendors.

In 2005, the contactless payments market had multiple card issuers
announce rollouts of contactless cards. Issuers and merchants targeted
8--10 major markets in 2005,[^68] with many more to follow. In addition
to the card issuers, many of the top national and regional retailers
have either enabled, or are in the process of enabling, their point of
sale (POS) systems to accept contactless payment cards.[^69] Some of the
advantages to the retail industry mirror those seen in the
transportation sector including speed, convenience, lower costs
resulting from fewer requirements to handle cash, improved operational
efficiencies, and reduced maintenance required by contactless readers.
This change in acceptance of smart cards will facilitate the ability of
transportation agencies to develop multi-use smart card fare payment
systems.

### 4.3.3 State of the Art {#state-of-the-art-10 .Style-Heading-3-+-Justified}

The use of contactless fare products is state-of-the-art in the U.S. The
LACMTA (Los Angeles) has implemented a state-of-the-art, multifunction,
contactless or proximity smart card for its employees, which was also
described in Section 4.2 when the overall fare system was discussed. The
smart card system will eventually be used by most of the regional
transit service providers' employees and their customers.

Washington Metropolitan Area Transit Authority (WMATA) recently launched
a three-year pilot project with a bank, where passengers can receive a
MasterCard with a smart card chip that allows them to pay fares,
parking, or make purchases with the same card.[^70]

The Chicago Regional Transit Authority (RTA) has two smart cards in use:
the Chicago Card and the Chicago Card Plus. The Chicago Card offers
touch-and-go boarding, a \$1 bonus for every \$10 of added value, and
fare protection. The Chicago Card Plus offers numerous benefits that
include fare choices, bonuses, online reloading over the Internet,
quicker boardings, account management, and protected fares. With
protected fares, if a Chicago Card Plus is lost, stolen, or damaged, the
customer can go online or call the CTA to report the problem. A
replacement card will be issued and the balance in the account at the
time the CTA was notified of the theft or loss will be restored.

There are several agencies demonstrating Limited Use (LU) Smart Tickets.
These low cost, throwaway, and sometimes reloadable cards are based on
Radio Frequency Interface Device (RFID) technology. The LU smart ticket,
similar to the smart card, contains a chip attached to an antenna that
is embedded into a paper-coated Polyethylene Terephthalate (PET) card.
It has limited memory and no processing. The cost of these cards is
lower than typical smart cards since they are physically less robust
with somewhat less functionality. These limitations are not expected to
be a problem since the expected period of use for the LU smart ticket
typically ranges from a day to a month. The LU smart ticket is deployed
in several cities in Europe including Paris, Capri, and Porto, among
others, and may soon be deployed at MARTA in Atlanta.

### 4.3.4 Emerging Trends {#emerging-trends-8 .Style-Heading-3-+-Justified}

The Massachusetts Bay Transportation Authority (MBTA) is introducing the
"Charlie Card," a contactless, stored-value smart card as a part of its
upgraded automated fare collection system. Additionally, the Port
Authority of New York and New Jersey is working on a smart card pilot
project for the Newark AirTrain and New Jersey commuter rail systems.

King County Metro in Seattle is still in the process of implementing a
regional, multimodal contactless smart card system. The system will
include a driver display unit that will serve as a single point of
communications and logon for various onboard systems such as fare
collection, AVL, and APC. For the fare collection system, all of the
back-office systems are built, but the Beta test of the cards onboard
the vehicles will not start until early 2006. Some of the innovative
features of the smart card system include:

-   "Right to Ride" with no actual value stored on the card. Instead,
    the card will store account information for a participating employer
    that provides transit subsidies to its employees;

-   The "Flat Rate" program, which reduces the administrative burden for
    employers that provide transit subsidies to their employees. The
    employer agrees to a flat rate for a certain period of time (e.g.,
    six months) to pay KCM, which in turn pays for the riding activity
    of its employees. The smart card fare collection system tracks
    employee ridership, and the data is used to adjust the flat rate for
    the next billing period;

-   Each participating employer can have secure access to a regional Web
    site to monitor and change elements within their fare payment
    program with KCM. The flexibility of the smart card, in conjunction
    with the Web site tools, provides many benefits such as increased
    convenience, increased ridership, decreased risks for employers,
    decreased administrative effort, a more cost-effective way to market
    transit via a wholesale employer-provided subsidy, and more data to
    fine-tune budgeting, communications, and marketing; and

-   A disposable card that can be used for tourists or shorter-term
    ridership that will not be reloadable or registered.

## 4.4 Clearinghouse/Regional Service Center (CH/RSC)  {#clearinghouseregional-service-center-chrsc .Style-Heading-2-+-Justified}

A regional fare system's Clearinghouse or Regional Service Center
provides a wide range of functionality. The functions may be allocated
to one or several organizations. For the purpose of describing the
technologies and functions, the guidelines presented in the *Major
Business Issues* document published by UTFS describes that "the function
of the CH is to provide the regional system with clearing, settlement,
and the associated financial reports and management information."[^71]
When the CH begins to offer additional services, it may more accurately
be described as a "regional service center" (RSC) rather than a
"clearinghouse."[^72] Depending on the size and scope of
responsibilities and the agreement between regional partners, the
institutional framework for establishing the Clearinghouse and Regional
Service Center may be implemented as a single entity or two separate
organizations.

There are a number of regional payment systems currently deployed, with
many more in the planning and development stages. Almost every major
metropolitan region is investigating the implementation of a regional
payment system to provide transit riders with a seamless and convenient
way to travel across the region using a single fare product. The ability
to implement these regional payment systems was enhanced through the
advancement of automated fare collection systems using smart cards. The
CH/RSC model is based on the need to pool, settle, allocate, and
distribute ridership revenue among regional carriers in a secure, fair,
and equitable manner. The regional agreements may be extended to create
economies of scale in the procurement, deployment, and maintenance of
automated fare equipment, as is the case with WMATA. The importance of
the institutional framework cannot be understated, as asserted by the
New York MTA:

> While riders will be most immediately affected by the fare media and
> readers that are chosen for the system, the selection of an
> institutional framework supporting a fare collection system is perhaps
> of greater importance to the success of the system than the choice of
> hardware to be used.[^73]

The primary functions of a Clearinghouse/Regional Service Center
include:[^74]

> Funds Pool Management;
>
> Settlement;
>
> Funds Distribution Procedures;
>
> Rules and Regulations;
>
> Security;
>
> Reports; and
>
> Change Management.

Other functions include:

> Card Base Management;
>
> Fare Policy Management;
>
> Load Procedures;
>
> Network and Equipment; and
>
> Marketing and Branding.

The "*Major Business Issues"* document referenced above is a best
practices guideline that describes how to establish and operate a
clearinghouse/regional service center. It was developed by APTA's UTFS
Financial Management Committee Business Process Work Group. The UTFS
document describes the key considerations for addressing business
process issues related to establishing a regional transportation payment
systems clearinghouse. The document describes original agreements,
funding provisions, and governance structures, including ownership,
board formation, and membership. Alternative models for operations and
management of the clearinghouse are also discussed.

The lessons learned documented in the UTFS Major Business Processes and
many publications by the Transit Cooperative Research Program[^75] have
established a clear, uniform set of guidance documents for public
transportation officials to consider when moving toward regional
coordination.

The CH/RSA can be a center that is operated in house, by a single
transit provider serving in the manager role, or by a contracted third
party. There are advantages and disadvantages to the various models.
Each of these models has been adapted by different regions. For example,
the Bay Area's TranLink® is operated by a contracted third party. CTA
operates its own clearinghouse and regional service center functions for
its Chicago Card and Chicago Card Plus programs. Similarly, New York
City Transit (NYCT) operates and manages the MetroCard, which is used by
NYCT and regional transit service providers.

### 4.4.1 Technology Description {#technology-description-10 .Style-Heading-3-+-Justified}

Since the clearinghouse serves the function of a critical data center,
the requirements for operating and maintaining a high volume, secure
transaction processing data center drive the technology. Accordingly,
the technologies associated with the CH/RSA are basic back-office
systems such as communication networks, servers, backup storage, and
software systems. For the clearinghouse and its technologies to operate
effectively, regions have learned that it is important to establish
procedures and standards that define service levels, monitoring efforts,
and mitigation procedures.

Deployment of the clearinghouse and its associated technologies and
equipment typically occurs simultaneously with the procurement and
installation of operator fare equipment (e.g., fare boxes/fare gates,
validators, balance enquiry machines, card readers), card vending
machines, parking devices, computers, and networks for the agency's
offices and garages.

### 4.4.2 State of the Art {#state-of-the-art-11 .Style-Heading-3-+-Justified}

The most successful and effective Clearinghouse/Regional Service Centers
depend on a well developed and thought out institutional framework
supported by technology. To be successful, a great deal of effort needs
to be put into the development of a governance structure, and procedures
for financial settlement, reciprocity reporting, customer service, and
card management.

Emerging standards in the fare collection area will make the deployment
of regional payment systems easier in the future. The technology
innovations that support the clearinghouse area are emerging along with
the standards. The UTFS standards will facilitate a common glossary and
will specify the following interfaces:

> A smart card data format;
>
> Data message sets from the card reader to the agency central computer;
> and
>
> Data message sets from the central computer to the CH/RSC.

One of the first clearinghouse/regional service centers was the
TransLink® system in the San Francisco Bay Area. Initiated by the MTC,
the effort was undertaken in response to the increased need for seamless
travel options throughout the Bay Area following the earthquake of 1989.
MTC spent many years developing the original agreements with regional
providers. Although MTC staggered deployment of the regional payment
system across the 34 regional carriers, as soon as a single operator
offered the regional payment method, the clearinghouse needed to be
operational.

In 1999 WMATA initiated a contactless smart card program, which went
through several stages. A thorough systems engineering analysis was
performed and a regional payment system was then proposed. WMATA and its
19 regional partners (in Maryland and Northern Virginia) identified key
issues, mostly institutional and policy related, in establishing the
Regional Service Center. The service center is responsible for two main
functions: clearinghouse activities and customer service (called the
Regional Customer Service Center or RCSC). The clearinghouse and
customer service center went live in January 2005. At the RCSC, the
contractor only performs the customer service center functions, with no
authority to provide refunds. The RCSC pools funds from bus, rail, and
parking revenue collection systems.

The regional agencies used the cooperative framework of the RCSC to
leverage WMATA's automated fare system procurement to purchase fare
equipment. This approach helped facilitate card sharing, thereby
simplifying the overall system. By sharing a common card and using a
common vendor, the following aspects of the RCSC were made possible:

> All participating agencies jointly fund the clearinghouse and customer
> service center. The fee is paid monthly and adjusted by ridership;
>
> Fees are apportioned by the amount of service provided;
>
> An agency's connection to the clearinghouse will be staged, based on
> their own development and deployment schedules;
>
> The headquarter's system for each agency will be connected using a
> common interface (called Data Network Concentrator --- DNC) developed
> by the vendor to the automated clearinghouse. This connection will
> also act as an audit trail to financial institutions;
>
> The common DNC interface made it easier to administer the
> clearinghouse functions in a regional setting; and
>
> A major component of the clearinghouse is a database that stores
> transaction information from all the regional partners. It includes
> settlement rules and generates a standard file for dispersing the
> revenue to the appropriate banks that represent the various transit
> agencies. The function then sends customer service information using a
> "service interface" to the Regional Customer Service Center.

WMATA and its regional partners sought to ensure that the service
interface was non proprietary. As such, they undertook the development
of an open interface called SIRS. WMATA determined that the cost of
using the clearinghouse approach and regional customer service center
for paratransit was too high at the time of the analysis.

## 4.5 Challenges and Lessons Learned  {#challenges-and-lessons-learned-8 .Style-Heading-2-+-Justified}

Moving the state of the art forward in the fare collection field has
been a relatively slow process, particularly in the area of regional
smart card fare collection systems. Most of the larger regional
installations have taken more time than originally planned, and many are
not yet fully implemented. Contributing to the problem is the fact that
larger systems are expensive because of the large amount of equipment
that needs to be purchased, and the extra care needed to protect revenue
security.

Some of the issues that have contributed to the slower pace of
electronic fare payment implementation are discussed below, including a
number of challenges and lessons learned.

### 4.5.1 Integration and Interoperability {#integration-and-interoperability .Style-Heading-3-+-Justified}

A principal challenge for deployment of electronic fare payment systems
is integrating equipment from different manufacturers. Some of these
issues arise when different types of fare collection equipment are used
within a system; others arise when a region is trying to have a system
used by one transit agency operate seamlessly with a different system
used by another agency. The issues are significant enough that the
Transit Cooperative Research Program (TCRP) recently funded a project on
smart card interoperability issues for transit.[^76] The project
identified several examples of complicating factors, including:

> Application of multiple fare-payment systems and technologies;
>
> Transit agencies' different operating needs and fare mechanisms;
>
> Inadequate communication protocols and information exchange among
> transportation clearinghouses;
>
> Absence of a single application programming interface to foster
> interoperability; and
>
> Intellectual property barriers that do not allow for open
> architecture.

Another major challenge has little to do with the interoperability of
the hardware and software, but rather with the robustness of the working
relationships among the various transit operators in a region. Agency
personnel need to understand that technology can only enhance existing
manual systems and organizational relationships; it cannot be expected
to create them where none had existed before.

### 4.5.2 Regional Systems {#regional-systems .Style-Heading-3-+-Justified}

Regional fare systems face additional complications from having to
integrate and be interoperable across multiple transportation agencies.
Clearly, as the number of participating agencies increases, so does the
potential for more issues. These issues have been systematically
resolved in a number of regions by advanced planning, a strong
commitment to collaboration, effective decision-making procedures, and
through a well thought out project architecture and system design.

Functional specifications and contract negotiations for integrated
systems take a significant amount of time to be developed. All parties
should be involved in each of the various development stages.

The resolution of fare policy issues, business rules, and revenue
reconciliation issues should be started very early and in parallel with
other requirements and development activities. There are many issues and
decisions to resolve, including those as basic as agreeing on common
fare category terminology (i.e., agreeing on the ages of children and
seniors eligible for discounted fares). Every agency interviewed
concurred that this process is very time consuming.

### 4.5.3 Standards {#standards-1 .Style-Heading-3-+-Justified}

Since integration and interoperability are such significant challenges
to implementing fare collection systems, particularly regional ones, a
large number of standards development efforts are ongoing. A
characteristic of standards for fare collection is that there are many
options and few comprehensive solutions. Additionally, the field of
standards has challenges of its own.

There are two efforts underway in the U.S. to generate standards for the
fare collection system. The APTA-managed Universal Transit Farecard
Standards (UTFS) program, a USDOT funded project, was initiated in 2001,
while APTA's Transit Communication Interface Profiles (TCIP) project
began developing the fare collection section of its work in 2004. In
addition, there are international standards development activities
underway with other standards emerging or being deployed throughout the
world.

Existing and emerging fare collection standards address requirements for
different levels within the overall system architecture. The Fare System
architecture, depicted earlier in Figure 4-1, illustrates four levels
where standards are currently being addressed. The fifth level, Level 0,
is the Media Level where standards for smart cards are represented. A
more detailed review of fare collection standards is included in Chapter
2, Integration.

The benefits from the fare collection standards efforts are still
emerging. Transit agencies need to determine which of the standards are
appropriate for their particular applications.

### 4.5.4 Equipment  {#equipment .Style-Heading-3-+-Justified}

There are numerous lessons learned regarding electronic fare payment
equipment from deployments of smart card-based systems:

> A number of transit agencies have reported that fare equipment
> maintenance can present challenges.[^77] Some problems stem from
> proprietary or more complex electronics, the need for new training,
> trying to do maintenance in the field on high-revenue routes, and
> dealing with dirty, bent, or damaged tickets.[^78] The equipment must
> function properly to maintain customer satisfaction (i.e., for the
> customer to buy fare media and board the transportation system) and
> for the transit agency to collect needed revenue and data. Maintenance
> standards and response time requirements need to be specified in
> advance.
>
> When rolling out new systems there is a time period when both the old
> system and the new system and their fare media must be maintained.
> This dual maintenance can be a significant burden on transit agencies,
> both operationally and in terms of cost of maintaining a dual system.
>
> When project planning allow ample time for equipment replacement or
> fare system upgrades as they tend to require extended time periods to
> successfully complete. Realistic project planning reduces the window
> of high risk with old, unreliable equipment.
>
> The process of getting multiple vendors, both of legacy and
> replacement equipment and systems, to work together to produce an
> entire working system often requires additional time and effort. Time
> for these likely delays should also be included in the project plan.
>
> Ensure that smaller, older vehicles have the wiring, battery power,
> and communications capacity to support the additional electronics that
> will be added to the vehicle.
>
> Fare products and equipment can be rendered obsolete by manufacturers,
> resulting in unavailable or unsupported products. For example, the
> type of smart card used in the ORANGES demonstration was discontinued
> by the manufacturer.
>
> Transaction speed is important, particularly in large, highly
> populated metropolitan areas. For example, the maximum amount of time
> to read a fare product, determine if it is a valid potential entry,
> and open a fare gate is usually set at 1.0 to 1.5 seconds. A number of
> systems operate even faster. Appropriate requirements for the total
> transaction time must be included in the system specifications.

### 4.5.5 Other Challenges and Lessons Learned {#other-challenges-and-lessons-learned .Style-Heading-3-+-Justified}

Some other miscellaneous challenges and lessons learned regarding
electronic fare collection systems include:

> When building systems for paratransit and human services providers the
> organizations may have fewer on-staff technical resources, which often
> places a stronger focus on client issues rather than transportation
> and technical issues. As a result, some categories of requirements and
> specifications may be better articulated than others. The project team
> will need strong technical support to assist with defining the full
> range of requirements.
>
> The cost of smart cards is still somewhat of a barrier, particularly
> for limited- use applications, such as for tourists and other
> infrequent riders. Even limited-use cards have still not achieved a
> low enough unit cost to effectively address the single journey issue.
>
> A number of business and technical issues can be barriers to
> developing partnerships with retail or financial partners. Some of the
> barriers will lessen as more standards emerge to reduce equipment
> incompatibilities and retrofitting costs. Overcoming other barriers
> simply requires negotiations skills and the initial selection of a
> relatively compatible partner organization. These barriers may include
> selection of compatible standards, cards, operating systems, security
> approaches, methods to upgrade, and point of sale terminals. Another
> issue involves potential changes in fraud exposure and liability. That
> is, determining who is responsible for fraud and liability issues with
> respect to multiple functions on a card.
>
> Rights to the use of intellectual property such as equipment
> interfaces, source code, or other proprietary information must be
> addressed in the agreements with contractor(s). The inability of
> public agencies to share key technical details with all contractors or
> with future contractors will inhibit competition in electronic fare
> collection system procurements. The inability to share these technical
> details with regional partners will inhibit coordination and
> interoperability.

Some of these barriers and issues have been resolved in various ways in
other countries, including numerous examples found in Europe. Finland,
for example, developed national smart card policies in the mid-1990s to
facilitate standardization and the broad use of smart cards in
transportation and municipal applications. Most agencies indicate that
the biggest advantages from smart card fare collection systems occur
when there are multiple uses for the card.

Ultimately, having a clear vision of what is expected from an electronic
fare collection system is important. Since vendors serve a range of
markets with different needs, it is essential to clearly articulate your
agency's overall vision and corresponding systems requirements.

## 4.6 References {#references-2 .Style-Heading-2-+-Justified}

Battelle Memorial Institute and Charles River Associates, "Evaluation
Strategy Puget Sound Regional Fare Card: FY01 Earmark Evaluation." USDOT
ITS Joint Program Office, Washington, DC (2003).

[www.itsdocs.fhwa.dot.gov//JPODOCS/REPTS_TE//13856.html](http://www.itsdocs.fhwa.dot.gov//JPODOCS/REPTS_TE//13856.html).

"Excellence in Customer Service in Transit Operations in Small to
Medium-Sized Cities in Western Europe," Transit Cooperative Research
Program, Washington, DC (2003).  TCRP Results Digest 64.

<http://trb.org/publications/tcrp/tcrp_rrd_64.pdf> .

"Government Smart Card Handbook." US General Services Administration,
Washington, DC (2004). 266 pp.

[www.smart.gov/information/smartcardhandbook.doc](http://www.smart.gov/information/smartcardhandbook.doc).

"In Your Pocket: Using Smart Cards for Seamless Travel," New York
Metropolitan Transportation Authority, October 2004.

"Regional Interoperability Standard for Electronic Transit Fare Payments
(RIS)." Port Authority of NY and NJ (2004).
[[www.panynj.gov/ris/]{.underline}](http://www.panynj.gov/ris/).

Smart Card Alliance. A not-for profit, multi-industry association
working to accelerate the widespread acceptance of multiple application
smart card technology. Their Web site identifies a wide variety of
resources*.*
[www.smartcardalliance.org](http://www.smartcardalliance.org/).

Smart Card Alliance, "Transit and Retail Payment: Opportunities for
Collaboration and Convergence." Princeton Junction, NJ (2003). 49 pp.

[www.smartcardalliance.org/alliance_activities/transit_retail_payment_report.cfm](http://www.smartcardalliance.org/alliance_activities/transit_retail_payment_report.cfm).

Technology Solution Providers, Assessment of ITS Deployments - Draft
Final Report, May 2005. 78 pp.

TCRP Project A-26, Smart Card Interoperability, Draft Report to be
issued in Fall 2005. Walter Allen, Acumen Building Enterprises,
Principal Investigator,\
[www.acumen-abe.com/](http://www.acumen-abe.com/).

UTFS Task Force Financial Management Committee Business Process Work
Group. "The Major Business Issues in Establishing and Operating Regional
Transportation Payment Systems and Clearinghouses." APTA, Version 2.01,
edited September 20, 2004. [www.apta.com](http://www.apta.com/).

# Chapter 5 Traveler Information

## 5.1 Introduction and Technology Overview  {#introduction-and-technology-overview-2 .Style-Heading-2-+-Justified}

ITS Traveler Information systems are vital for both customers and
transit agencies. For customers, the systems help them learn about and
use the various public transportation services offered. For transit
agencies, Traveler Information systems lessen the burden on staff who
provide customer information, and the agency's overall telephone system.
In addition, transit personnel frequently use the information systems
themselves to locate information when working to improve transit
services. Other benefits include reduced incoming phone calls seeking
transit information, shorter phone calls, fewer dropped calls, increased
ridership from new and existing patrons, increased customer
satisfaction, less e-mail correspondence, and faster access to service
information when researching problems.

Data provided by Traveler Information systems can consist of relatively
static data elements such as schedules and fares, or more dynamic
elements such as estimated real-time arrival times, route delays, and
traffic flow conditions. The accuracy of the data provided to the public
is essential and depends on constantly updating a number of integrated
data sets. Those data sets might include scheduled service, changes to
scheduled service, fare tables, special events, service disruptions, bus
stop names and locations, landmark names and locations, street names and
alternative names, addresses, and transportation network information
including private roads, walking paths, and other modal paths. Travelers
may need this information for trip planning purposes, at trip
commencement to verify key pieces of information, or while enroute
(particularly if incidents or service disruptions occur).

With the advent of regional trip information systems that span multiple
jurisdictions, the resources needed to integrate these data sets and
keep them accurate become even more challenging. The challenges stem
from the fact that regional transit trip information typically requires
the integration of dissimilar data sets from multiple agencies to
support multi modal and multi agency trip planning and transit
information. Examples of the data needed for regional trip planning
applications include interagency and intermodal transfer locations,
multi agency transit center walking directions, regional consistency in
naming and locating services (including stops and stations), a common
set of landmark and street names, a common base transportation network,
and location references. The use of standards and established regional
procedures is necessary to maintain and improve data quality.

Because of the difficulties faced by transit agencies in developing,
managing, and maintaining the data for traveler information systems, a
section titled "Transit Trip Information Infrastructure" is included in
this chapter. It highlights some of the critical information
infrastructure elements identified by transit agencies regarding
state-of-the-art systems. By having an effective infrastructure to
support traveler information systems, it is easier to provide more
information options, information products can be more cost-effectively
produced, operating impacts are minimized, and investments in software
and data can be leveraged.

## 5.2 Transit Information Systems {#transit-information-systems .Style-Heading-2-+-Justified}

### 5.2.1 Technology Description {#technology-description-11 .Style-Heading-3-+-Justified}

Table 8 summarizes the various types of Traveler Information systems
used in transit today. The systems vary in several ways. The information
provided can be static or real-time information. Many of the systems
provide pre-trip information, but an increasing number of them are
providing information onboard the vehicle, in transportation terminals,
or on personal information devices such as cell phones. New information
products and services are also being provided such as customized
timetables or interactive maps.

Traveler Information systems are moving away from "stovepiped,"
stand-alone vertical systems to more integrated systems that make a
variety of services available through multiple "channels." Examples of
channels include Interactive Voice Response (IVR), data tables or
interactive maps on the Web, dynamic message signs at transit stops or
on the vehicle, voice annunciators, or Instant Messages to cell phones
or personal digital assistants (PDAs). An emerging capability is to
reuse some system modules or services (e.g., a dynamic timetable
generator) to provide similar pieces of information (e.g., planned
schedule data and real-time estimated arrival times).

Some of the more significant advances have occurred in the area of
integrated regional traveler information systems. In particular, the
advances have been through 511 telephone information systems and
technology infrastructure improvements that allow better and easier
access to transit data.

[]{#__RefHeading___Toc129324328 .anchor}Table 8 Types of Traveler
Information Systems

+-----------+------------------------------+--------------------------+
| **Subcat  | **Description**              | **Example Technologies,  |
| egories** |                              | Business Processes, or   |
|           |                              | Software**               |
+===========+==============================+==========================+
| Transit   | Addresses the many ways of   | Pre-Trip                 |
| In        | obtaining traveler           |                          |
| formation | information including        | Customer information     |
| Systems   | pre-trip, personal,          | systems for trip         |
|           | in-terminal / wayside, and   | planning                 |
|           | in-vehicle information       |                          |
|           | systems.                     | Customer call centers    |
|           |                              |                          |
|           | Pre-trip systems include     | Web                      |
|           | information obtained before  |                          |
|           | departing on a trip. Can be  | Provision of schedules   |
|           | static and/or real time, and | and next bus information |
|           | may include transit routes,  | through a variety of     |
|           | maps, schedules, fares,      | channels                 |
|           | park-and-ride lot locations, |                          |
|           | transit trip itineraries,    | May include incident     |
|           | paratransit information,     | notification, transit    |
|           | special events, service      | vehicle arrival alert,   |
|           | disruptions and revisions,   | or other subscription    |
|           | etc. Channels that           | information              |
|           | disseminate pre-trip         |                          |
|           | information include the      | Route maps and bus stop  |
|           | telephone, Internet,         | locations                |
|           | electronic kiosks, fax       |                          |
|           | machines, television,        | > Custom travel profiles |
|           | personal systems (see        | > and subscription       |
|           | below), etc.                 | > services such as       |
|           |                              | > real-time alerts and   |
|           | Personal systems include     | > static schedule        |
|           | information accessed through | > downloads              |
|           | PDAs, cell phones, and       |                          |
|           | laptop computers prior to,   | Personal Information     |
|           | or during, a trip.           | Systems                  |
|           |                              |                          |
|           | In-terminal systems provide  | PDAs                     |
|           | arrival/departure            |                          |
|           | information for buses/trains | Laptops                  |
|           | at bus stops, terminals,     |                          |
|           | train stations and           | Cell phones              |
|           | platforms. Information is    |                          |
|           | displayed on monitors,       | In-Terminal Information  |
|           | variable message signs, sign | Systems                  |
|           | boards, passenger            |                          |
|           | information displays, and/or | At stops and stations    |
|           | electronic kiosks. May       |                          |
|           | provide static (scheduled)   | Also includes facility   |
|           | or real-time information.    | status information       |
|           |                              | (e.g., elevator/         |
|           | In-vehicle systems provide   | escalator outages)       |
|           | automatic visual and/or      |                          |
|           | audio announcements on       | Infrared signage (e.g.,  |
|           | transit vehicles. Typical    | talking signs) allowing  |
|           | announcements include next   | sight impaired customers |
|           | stop, major cross road,      | to orient themselves     |
|           | transfer point, landmark,    | within the station       |
|           | and destination information. | environment              |
|           | Additional information, such |                          |
|           | as public service            | In-Vehicle Information   |
|           | announcements and            | Systems                  |
|           | advertisements, may be       |                          |
|           | provided at other times.     | Annunciator and signage  |
|           | Complies with Americans with | provided inside and /or  |
|           | Disabilities Act (ADA)       | outside of the transit   |
|           | requirements.                | vehicle                  |
|           |                              |                          |
|           |                              | Personalized Transit     |
|           |                              | Information              |
|           |                              |                          |
|           |                              | Transit status based on  |
|           |                              | traveler's itinerary,    |
|           |                              | sent to traveler via     |
|           |                              | e-mail or Web page       |
+-----------+------------------------------+--------------------------+
| M         | Includes the use of any type | 511 systems              |
| ultimodal | of traveler information      |                          |
| Travel    | channel (call centers,       | Regional or multi-agency |
| In        | kiosks, Internet, telephone, | systems                  |
| formation | cell phones, PDA's, pagers,  |                          |
| Systems   | etc.) to provide real-time   | Can include both         |
|           | and static information on    | integrated information   |
|           | transit, traffic and other   | and agency specific      |
|           | modes to enable travelers to | information              |
|           | make fully informed mode     |                          |
|           | choice decisions both        |                          |
|           | pre-trip and enroute.        |                          |
+-----------+------------------------------+--------------------------+

### 5.2.2 State of the Art {#state-of-the-art-12 .Style-Heading-3-+-Justified}

This section discusses state-of-the-art Traveler Information services
that are currently implemented at transit agencies. A number of Traveler
Information systems that are state of the art are also described in
Section 5.3.2, which focuses on the data and information infrastructure
advances, and in Section 5.4, which highlights some emerging Traveler
Information technology trends.

In recent years, advances in database tools and Web services have
facilitated the development of more specific query options for customers
and staff. Instead of having to become a skilled user of more
complicated (yet more flexible) trip planner tools, customers can use
custom applications tailored to obtain explicit information, such as to
identify all services available near a given location or to produce
customized timetables.

Improvements in Geographic Information System (GIS) tools, Web access
and speed, and in interactive Web mapping technologies allow easier and
better querying and displaying of geographic data. Transit agencies are
now able to provide a variety of different map views and tools to their
customers to meet different needs and preferences.

Improvements in the speed and accessibility of wireless communications
are changing, and will continue to change, the way in which transit
agencies are able to provide traveler information. At some agencies,
transit staff and customers can now access information at bus stops and
onboard vehicles. The increasingly widespread use of cell phones and
PDAs now allows mobile access to telephone information and Web browsers.

State-of-the-art ITS applications discussed below either provide new
services to transit customers, employ new dissemination modes or
channels, provide answers more clearly through improved formats and
representations, and/or provide the information more quickly for transit
staff and customers. Advances in Traveler Information also facilitate
regional travel, travel across different transit providers, and the use
of different transportation modes. Examples of these advances include:

> Capital Metro in Austin, TX has improved its paratransit service for
> both the customers and transit staff through the use of an automated
> dial-out ITS application that calls clients to inform them of changes
> in their pick-up times.
>
> NJ Transit (NJT) rail customers benefit from a Web-based
> station-to-station trip planning function (See Figure 18). The
> specialized tool is simpler to use for planning rail trips than the
> general Itinerary Planning system. Other tailored trip planner tools
> include an option to locate services near a particular location, bus
> routes by county, and station-to-station light rail schedules.
>
> In August 2005, the RTA (Chicago) announced a new cell phone and PDA
> accessible Traveler Information Web Site. Called RTA Mobile, the new
> site can be accessed at www2.rtamobile.com by Internet-enabled cell
> phones and PDAs. It provides the wireless Internet version of the
> RTA's Itinerary Planning System. Over time, RTA will add more
> capabilities to the site. The wireless Web site is anticipated to
> decrease calls to the RTA Travel Information Center and provide new
> information options to the traveling public.
>
> Real-time tracking of transit vehicles has become more common.
> Real-time transit information can be provided over the Internet, via
> telephone, on the vehicle, and at the wayside. Many of the displays
> are more attractive and easier to view. For example, real-time bus
> tracking services that appear on a map are available at TriMet
> (Portland, OR) via their Transit Tracker service, at King County Metro
> (Seattle, WA), and Cape Cod Transit (Hyannis, MA). Cape Cod's
> real-time bus tracking tool serves both fixed route and paratransit
> service. For their rural service, with longer headways and flag stops,
> this tool has helped customers know when to go out to the road to flag
> down the bus.[^79] In another example, the Washington State Ferry
> System displays the position of ferries on an Internet map with the
> assistance of Global Positioning System (GPS) technology.
>
> Estimated arrival times of transit vehicles are displayed at key bus
> stops and transit centers at a variety of transit agencies. Los
> Angeles County Metropolitan Transportation Authority (LACMTA) displays
> estimated real-time arrival times for some Bus Rapid Transit (BRT)
> vehicles on Light Emitting Diode (LED) display signs located at major
> bus stations. The City of San Luis Obispo (SLO) Transit uses a
> relatively low-cost approach that involves sending a text message
> about the bus's expected arrival time via a pager to solar-powered
> "Smart Transit Signs" at the next bus stop. In Colorado, the Regional
> Transportation District (RTD) provides estimated arrival times at key
> locations, on the Web, and via wireless options.
>
> A number of wireless options for accessing transit traveler
> information are provided by the RTD as shown in Figure 18. Customers
> can download schedule data to PDAs, register for e-mail updates, call
> for predicted arrival times of RTD buses and trains, download custom
> schedules, and navigate to a special Web site designed for mobile
> phones and PDA browsers to obtain real-time arrival information.
>
> Interactive mapping of transit routes, facilities, and other
> transportation services has improved and become more commonplace. For
> example, TriMet has some easy to use, fast, and attractive
> applications that allow the user a range of specific query and display
> options. Figure 19 shows the agency's interactive map that allows a
> user to zoom to a variety of levels and obtain mapped information on
> bus stops, routes, light rail stations, transit centers, and
> park-and-ride lots located near a specified location. Interactive rail
> maps can be seen on the Web sites for LACMTA and the Washington
> Metropolitan Area Transit Authority (WMATA). In addition, the Dundee
> City (Scotland) Journey Planner works with a very easy and clear
> interactive map.[^80]
>
> Regional traveler information systems, particularly 511 telephone and
> web applications, are being implemented across the U.S. Many of the
> 511 systems are using voice recognition tools as part of the
> phone-based Interactive Voice Response (IVR) system. Transit
> applications are beginning to be incorporated into the 511 systems,
> which have typically started with traffic-related information. The
> multi modal trip planning tools also support Transportation Demand
> Management (TDM) efforts in a region. Parking and parking management
> applications will become another integral component of these systems.
>
> The 511.org Web site that supports the San Francisco Bay area includes
> information on traffic conditions, transit (including access to the
> regional Trip Planner), ride share, bicycle, and other
> transportation-related information. Approximately 40 organizations
> have links to the Web site and approximately 24 transit agencies are a
> part of the Trip Planner service.

[]{#__RefHeading___Toc129324160 .anchor}Figure 18 NJ TRANSIT
Station-to-Station Application

![](media/image29.png){width="6.510416666666667in"
height="4.104166666666667in"}

[]{#__RefHeading___Toc129324161 .anchor}Figure 19 Wireless Options for
Traveler Information at RTD-Denver

![](media/image30.png){width="6.041666666666667in"
height="3.3291666666666666in"}

[]{#__RefHeading___Toc129324162 .anchor}Figure 20 Example of TriMet's
Interactive Mapping Options

![](media/image31.jpeg){width="6.375in" height="3.8784722222222223in"}

## 5.3 Transit Trip Information Infrastructure {#transit-trip-information-infrastructure .Style-Heading-2-+-Justified}

### 5.3.1 Technology Description {#technology-description-12 .Style-Heading-3-+-Justified}

The transit trip information infrastructure is the "behind the scenes"
blend of information technology tools and agency procedures that ensures
the availability of data needed to provide transit trip information to
the customer. The infrastructure described here supports both
single-agency and regional approaches to ensuring an integrated set of
data that supports scheduled and real-time trip information services, as
well as different channels used to disseminate the information to
travelers. The information infrastructure description was developed
based on a combination of "best practices" information and lessons
learned from the transit agencies interviewed. Communications technology
infrastructure and issues, such as for wireless communication, are
discussed in the Communications section of Chapter 2.

An effective trip information infrastructure is now of much more
importance to transit agencies because of the large number of different,
yet related, traveler information systems and channels that are being
employed, as shown in Table 5-1. Transit agencies cannot afford to have
redundant and inefficient data development and maintenance efforts for
multiple systems.

Although most transit agencies distribute customer information via
automated systems, data that feeds the systems are often developed and
managed with manual, resource-intensive processes that require a
significant investment of ongoing staff time to provide up-to-date
information on a daily basis. These resources are even more pronounced
when service changes are made and various regions are involved. If the
data provided by traveler information systems are not accurate, the
systems can either fail or not be fully used.

Newer IT technologies such as Web services and the development of a
back-office data infrastructure can both help reduce the additional
staffing requirements. Although few agencies have taken full advantage
of the technology options available, there are some key examples of
next-generation infrastructure tools and systems that clearly show the
benefits of deploying a state-of-the-art transit traveler information
infrastructure. Some of these examples are described below in Section
5.3.2, State of the Art.

A robust, state-of-the-art transit trip information infrastructure will
support the incremental rollout of multiple traveler information
services provided to multiple user communities, such as accessible
information or information in other languages. The distinguishing
features of a traveler information system infrastructure can be
classified into three categories:

> Technological Features
>
> Data Integration Issues
>
> Regional Considerations

#### 5.3.1.1 Technological Features {#technological-features .Style-Heading-4-+-Justified}

The technological features that enable the enhancement and more creative
uses of transit data consist of:

> Data-driven applications: Use of data management tools and techniques
> such as data models and sophisticated database design offer advantages
> over legacy application programming techniques that, even when using
> database technology, result in "stovepiped" applications and highly
> customized, difficult to maintain environments. A good example of a
> data-driven deployment is found at Metropolitan Transportation
> Commission (MTC) based in the San Francisco Bay area. MTC's Regional
> Transit Database is referenced geographically and includes a data
> engine that can integrate spatially related data "on the fly."
>
> A "three-tier" or "N-Tier" computing architecture: Use of a three-tier
> computing architecture (e.g., one tier would be the databases, another
> tier might be the business rules and applications, and a third tier
> might be the distribution channels for the information such as the
> Web) allows the separation between databases, business processes, and
> presentation to enable modularity, flexibility, and easier system
> changes.
>
> The use of open systems and standards: "Scalable" hardware and
> software approaches that enable the use of information technology (IT)
> and Web-based standards, commercial off the shelf software (COTS), and
> other technology systems are especially important "...to enable
> properly engineered components to be utilized across a wide range of
> systems with minimal changes, to interoperate with other components on
> local and remote systems, and to interact with users in a style that
> facilitates portability."[^81]

#### 5.3.1.2 Data Integration {#data-integration .Style-Heading-4-+-Justified}

The successful integration of transit data is also a key factor in
supporting Traveler Information systems. There is a wide range of ways
to integrate data to provide this support. For example, the integration
of data needs to occur between a variety of data sets, a mechanism needs
to exist to ensure that bus stops are accurately sequenced and
integrated into the appropriate route patterns, and schedule and route
data to support interim changes must be included as part of the data
resources. Additional information pertaining to integration benefits,
techniques, and issues is provided in Chapter 2, Integration.

#### 5.3.1.3 Regional Deployment Considerations {#regional-deployment-considerations .Style-Heading-4-+-Justified}

Regional traveler information systems have extra, and somewhat more
complex, components to their information infrastructures. They have
extra issues with respect to the integration and quality checking of
multi-agency data sources, more complex coordination and administrative
procedures, and, if they are providing real-time data, they potentially
have to manage differences in the quality of the real-time data.

##### 5.3.1.3.1 Coordination and Administration Processes {#coordination-and-administration-processes .Style-Heading-5-+-Justified}

A clear theme that emerged from the literature search and the interviews
is that successful regional traveler information systems need a
significant level of coordination in place between the partners and a
number of administrative processes to be successful. For example, one
element of a successful regional transit traveler information system is
the effective handling of the schedules from the different transit
partners. Agencies within a region may not change their schedules on the
same date, and they may not have the same number of schedule changes in
a year. In some cases, the new schedule version may apply to only a
portion of an operator's schedule (e.g., one division or base such as a
vehicle garage) rather than across the entire organization. As a result,
clearly understood standards and procedures are needed to ensure that
adequate configuration control and documentation of schedule data from
the different agencies is achieved.

The solution for resolving this issue depends on the complexity of the
differences between the partner agencies. For example, the Puget Sound
Area updates their trip planner system every two weeks to manage the
major and interim changes to the regional system. The San Francisco Bay
Area's MTC "TakeTransit Trip Planner" manages the major schedule changes
two weeks prior to the schedule change for each agency.

##### 5.3.1.3.2 Real-Time Data Quality Management {#real-time-data-quality-management .Style-Heading-5-+-Justified}

A number of regional organizations are developing plans for presenting
multi-agency and real-time information to their customers. A key
challenge for these regional organizations is determining how best to
present the data to the public in a reasonably consistent manner when
the information accuracy varies between each transit agency. For
example, the transit agencies may have GPS and AVL systems from
different vendors and technology eras. The systems may also provide data
at different frequencies (e.g., anywhere from one to five minutes),
different levels of accuracy (e.g., 0.5 to 250 feet), or from different
algorithms that provide the estimated time of arrival differently (e.g.,
is the arrival time estimated for a bus stop, or is it calculated as a
schedule deviation from last time point).

### 5.3.2 State of the Art {#state-of-the-art-13 .Style-Heading-3-+-Justified}

A number of transit agencies have developed Traveler Information system
data infrastructures that operate in an integrated manner, both
internally and regionally. The benefits that arise from these
state-of-the-art Traveler Information infrastructures include:

> The ability to have a more flexible, modular, and scalable system;
>
> The ability to be expanded to include other data sets and other
> presentation methods or channels over time; and
>
> A more cost-effective approach to data development and maintenance.

The following are examples of transportation agencies that have
developed data infrastructures that support regional Traveler
Information.

> The RTA in Chicago provides regional oversight for three transit
> providers: Chicago Transit Authority (CTA), Pace Suburban Bus, and
> Metra. As a regional organization the RTA coordinates and integrates
> its Traveler Information projects with respect to the regional
> setting, the different transportation agencies, and the variety of
> transportation modes in the region. RTA is also helping to create the
> Illinois Transit Hub, which is a central repository for CTA, Pace,
> Metra, and other agencies. It collects data and establishes data
> interfaces and regional procedures. With centralized data, it can
> provide or display information to a range of agencies and customers,
> and through a variety of channels. RTA is also in the process of
> building a system to provide real-time vehicle location information to
> the public. Once data become available, they will be provided first to
> its Call Center and then to information signs.
>
> King County Metro has made substantial investments in the design and
> development of its data infrastructure. Core data are defined by the
> agency, and they have a central source for those data. Each
> application may access the core data and transform that data as
> needed. The data maintenance procedures and accuracy standards are
> defined, and relationships among data elements are resolved in data
> committee meetings. The Customer Services group plays a key role in
> ensuring data quality for the Traveler Information systems by
> performing data updates and checking for errors in the data sets.
> Spatial data are available both to the GIS and the relational database
> system, allowing for easier links between spatial data and tabular
> data. A range of tools and utilities have been developed for
> facilitating data maintenance, locating bus stops on a map,
> identifying bus stop sequences, and conducting ad hoc data queries.
>
> Portland TriMet has also invested in a well-planned transit and
> spatial data infrastructure that allows the agency to provide their
> staff and customers with a wide range of flexible Traveler Information
> tools. One of the areas in which TriMet excels is the spatial display
> of transit routes, facilities, and other information for the traveler.
> Their ability to do this is facilitated by their development and use
> of a location referencing authority table (Location Table). The
> Location Table serves as the "authority" for location references for
> transit point features. For example, a bus stop identified in the
> table with a unique ID number would be associated with several
> location reference methods such as the latitude and longitude, offset
> from the "at" and "cross" streets, and/or address. There are several
> benefits to having a Location Table as part of the Traveler
> Information data infrastructure, as described in the agency's
> "Location Referencing Guidebook." [^82]
>
> The MTC in the San Francisco Bay Area has developed, maintained, and
> operated a complex data infrastructure to support its 511 and regional
> Trip Planning systems. This infrastructure includes a Regional Transit
> Information System (RTIS) that serves as a centralized source of data
> and services that can be accessed over a wide area network (WAN) by a
> variety of agencies and users. It supports multiple applications
> developed by the regional transportation partners.
>
> Some of the goals of the RTIS include:
>
> Avoiding data duplication;
>
> Optimizing data maintenance;
>
> Minimizing expenses;
>
> Upgrading the quality of the data;
>
> Sharing valuable resources;
>
> Supporting multiple applications with the same data set; and
>
> Improving access to the data.
>
> Critical to meeting these goals is the use of standards, an open
> architecture, a well-developed data structure, institutional
> commitments, and documented agreements on how to support the system.
>
> The major components of the RTIS include:
>
> A relational database;
>
> An open data structure;
>
> A central spatially-enabled database;
>
> GIS functionality;
>
> A communication network;
>
> Open access to MTC's transportation partners; and
>
> Analysis tools.

## 5.4 Emerging Trends {#emerging-trends-9 .Style-Heading-2-+-Justified}

A number of technology advances have occurred with respect to wireless
communications, Web tools, geographic information and mapping tools, and
data management that will drive the potential for some significant
advances in Traveler Information services and the ease of providing
them.

In particular, advances in mobile WiMAX and Dedicated Short-Range
Communication (DSRC) technologies (see Communications section of Chapter
2) will provide more options for communicating information to and from a
moving vehicle, helping to communicate arrival and departure times as
well as other information. Communication to bus stops can occur with a
wireless network and the use of Internet Protocol (IP) addresses.

In the very near future, technology enhancements will provide faster
answers and more functionality, including interactive mapping that is
quick and intuitive to use. However, it is not known when transit
agencies and current transit trip planning vendors will be able to take
advantage of these new trends.

Public data information repository tools will provide private Web
promoters (e.g., GoogleMaps, MapQuest, HopStop, BusMonster, etc.) the
ability to offer attractive, user-friendly traveler information and
multimodal trip planning Web services. These services may be available
via Web, voice over Internet protocol (VoIP), and mobile devices (e.g.,
cell phones, PDAs, etc.). They may integrate several data sources such
as transit service, bicycle paths, traffic congestion, and incident
information to provide users with several transportation alternatives
and linked trips. In all likelihood these Information Service Providers
will offer links or interfaces such as Application Programming
Interfaces that transit agencies could use to customize these functions
into their own Web sites. However, the applications may not initially
support the following:

> Fare data;
>
> Trip selection based on minimization of cost;
>
> Call center support capability (customer care, customer complaints and
> commendations);
>
> Full array of IVR services;
>
> Free unlimited access (transit agencies my be charged use fees if they
> run over a certain number of transactions); and
>
> Turn-key installations located on an agency-owned or operated Web
> site.

### 5.4.1 Examples of Emerging Trends {#examples-of-emerging-trends .Style-Heading-3-+-Justified}

Examples of emerging technologies that have resulted in state-of-the-art
Traveler Information projects that are planned or currently under
development include:

-   New multimodal 511 systems with transit components (Voice Over
    Internet Protocol (VoIP) is under consideration for some of the
    projects);

-   The use of wireless technology on buses so customers and operators
    can receive information;

-   The use of wireless technology and IP addresses to support the
    communication of traveler information from the vehicle to wayside
    signs;

-   New mapping and imaging tools;

-   More complicated uses of voice recognition software; and

-   Automatic integration of itinerary planning and real-time bus and
    rail status to provide personalized travel information tailored to
    each individual traveler's circumstances.

    Below are specific examples of emerging trends in state-of-the-art
    Traveler Information applications.

> King County Metro is in the process of outfitting 30 buses with
> equipment to provide WiFi access on the bus for passengers. In this
> initial demonstration project to provide Internet access to passengers
> while in transit, commercial cell phone carrier infrastructure will be
> used to communicate the data from the bus WiFi hot spot (i.e.,
> wireless access point for connecting to the Internet).
>
> The RTA in Chicago was recently awarded a \$1 million grant from FTA
> to develop a Multimodal Trip Planning System (MMTPS), which will
> provide point-to-point directions for transit trips, driving trips,
> and other transportation modes. The goal is to provide users with a
> real-time, decision support tool to offer them the best travel
> options, considering mode, efficiency, cost, and convenience. The
> MMTPS will be developed using Transit Communications Interface
> Profiles (TCIP) and Advanced Transportation Information Systems (ATIS)
> standards in Extensible Markup Language (XML) to integrate existing
> single-mode trip planning and traveler information systems. 
>
> Decisions will likely take into consideration:
>
> Real-time incident data;
>
> Highway congestion (travel times) data;
>
> Integration of the existing transit system and highway data; and
>
> Illinois DOT (IDOT) and local DOT highway/arterial monitoring system
> data.
>
> The project is proceeding under a three-phased approach. Phase 1 will
> develop the core system, which will provide itineraries for a trip
> made by transit, driving, and a combination of the two.  It will
> include real-time highway information.  Phase 2 will add functionality
> to the core system and will include real-time arterial data, real-time
> transit data, parking information, bicycling information, emissions
> avoided calculations, and paratransit dispatching. In the third phase,
> the system will incorporate other intercity operators and broader
> participation (e.g., Amtrak, Greyhound, and Gary-Milwaukee).
>
> RTA is also planning to provide real-time transit information from the
> three transit agencies it oversees (CTA, Pace, and Metra). The system
> will incorporate real-time data from the automatic vehicle location
> (AVL) systems of all three agencies. Planned schedule data will be
> collected into three separate databases using the native formats
> provided by each operating agency. RTA staff will work with the
> respective agencies to verify and validate the datasets. After the
> data are validated, they will be normalized, projected to bus stop or
> station level schedules, and stored in a central database. Real-time
> data feeds will come directly from each agency's communications center
> to the RTA server where they will be extracted, transformed, loaded,
> and made ready for distribution.
>
> Capital Metro, Austin, TX, is in the process of implementing IVR
> access to their Trip Planner system using voice recognition software.
> The agency is working to make the implementation more robust, which
> includes dealing with the multiple languages and accents that are
> common in the Austin area.
>
> Two advanced parking management and information systems are currently
> being implemented, one in Montgomery County, MD, and the second by
> Metra in the Chicago area.  The Montgomery County system will inform
> motorists via portable Dynamic Message Signs (DMS) when the parking
> station is full, and suggest that they park at an alternate satellite
> parking lot or at another station parking facility. 
>
> The Metra Parking Management Guidance System is a two-year
> demonstration project that includes eight DMSs located in a corridor
> with two commuter rail stations. Loop detectors in the pavement at the
> rail station parking areas will detect cars entering and leaving the
> lot. Information from the loop detectors will be sent to a software
> system that will estimate the available parking (taking into
> consideration passenger drop-off activity and other factors necessary
> for estimating fill rate) and determine the message to be sent via
> wireless communications to the DMSs. The DMSs will provide motorists
> with a real-time estimate of the number of available parking spaces at
> the respective stations.  If parking at a station is unavailable the
> sign will indicate that the lot is full and suggest an alternative
> parking option. Additional information on parking management is
> provided in Chapter 7, Transportation Demand Management.
>
> TriMet is currently in discussions with GoogleMaps to explore options
> for providing easier to access, more attractive traveler information,
> and possibly more mapping views to its customers. The agency is also
> in the process of implementing a Dynamic Timetable Generator (DTG) to
> more quickly and efficiently update their schedule data on their Web
> site. A prototype of the DTG was originally developed as a part of the
> TRB Transit IDEA Project 39. The DTG prototype application was built
> using multiple standards (e.g., TCIP, XSLT) and open source software
> (Apache Web Server, MySQL, Linux, and Tomcat) to ensure that the
> system was an "open" one. The prototype was built using a
> database-driven approach to derive the information from the native
> authority, and a 3-tier computing architecture to enable migration to
> different agency native formats and timetable presentation formats
> (e.g., color schemes, ADA formats, etc.).
>
> On Cape Cod in Massachusetts, a prototype demonstration of an
> *e-transit village* is ongoing*,* which includes using buses as "WiFi
> hotspots" and implementing state-of-the-art transit ITS applications.
> The project is currently being conducted by the GeoGraphics Laboratory
> at Bridgewater State College using the campus transit system provided
> by the Brockton (MA) Area Transit Authority. One of the project's
> goals is to use affordable, off-the-shelf products, standards, and
> open-source software wherever possible.
>
> The proof-of-concept project uses a wireless local area network
> infrastructure (WLAN) on campus and international standards (WiFi or
> wireless fidelity 802.11b). Transit buses are equipped with
> custom-built mobile data computers that contain global positioning
> system (GPS) receivers, which communicate with the campus outdoor WiFi
> network through a high-powered wireless card and an external wireless
> antenna. All hardware is COTS, while the software is freeware (e.g.,
> Linux) or resides in the public domain.
>
> The mobile data computers also have an emergency alarm and an Internet
> video camera. The Internet camera can be controlled remotely by the
> operations center to pan, tilt, and zoom. Custom-built software stamps
> the image file from the Internet camera with GPS date/time and precise
> latitude and longitude information, and then transmits the image at
> one-second intervals to the GeoGraphics laboratory's Web server and
> database using Internet protocols. As a result, the following transit
> ITS applications can be provided:
>
> Each bus can act as a mobile Internet access point (AP) for
> WiFi-capable laptops and PDAs used by campus community bus patrons;

-   The system provides AVL Web-mapping with one-second refresh rates.
    It also provides the estimated time of arrival of each vehicle at
    principal bus stops. Transit vehicle location can be accessed by
    customers in the community at their desktop or on campus kiosks,
    from their wireless laptop/PDA at bus stops, or while onboard the
    bus; and

-   To provide better emergency response, real-time onboard video is
    transmitted at one-second refresh rates to the Operations Center,
    Police Department Dispatcher, and to first responder vehicles when a
    MAYDAY alarm is signaled. During all other times, video is
    transmitted in real time over the Internet and to video archives
    posted at the GeoGraphics Lab Internet site. A transit consumer can
    use these services to see video from the approaching vehicle and
    potentially recognize where the bus is on its route.

    The demonstration project has succeeded at most of its goals. The
    project team is now working on resolving those issues that afflict
    most mobile wireless demonstrations, that is, how to maintain a
    connection when moving between WiFi locations. AVL data are
    transmitted every second without difficulty, but the transmission of
    large blocks of video data in real-time sometimes results in dropped
    signals. The project is also exploring how to extend the range of
    the wireless capabilities to more rural areas.

## 5.5 Challenges and Lessons Learned  {#challenges-and-lessons-learned-9 .Style-Heading-2-+-Justified}

Developing accurate, timely, and complete data for the traveler
information systems is one of the biggest challenges to implementing
advanced traveler information systems. If the data are not correct, the
systems will not operate efficiently or effectively. When the
information provided to travelers is not dependable, the systems will
not be fully used. Customers will stop using a system or the transit
agency will terminate the service because of the ill will generated with
customers when incorrect information is provided. Similarly, transit
agency customer information staff will not use trip planning systems
when the data in the system is old or incorrect, preferring instead to
rely on their internal knowledge, manual references, or other data
sources.

### 5.5.1 Key Lessons Learned {#key-lessons-learned .Style-Heading-3-+-Justified}

The most important lessons learned by those transit agencies interviewed
are to:

> Allow adequate time to develop the necessary data, and ensure that
> they will be correct and available when the system is to be
> implemented; and
>
> Ensure that processes and resources are in place to address ongoing
> data maintenance.

### 5.5.2 Regional Trip Planning Lessons Learned {#regional-trip-planning-lessons-learned .Style-Heading-3-+-Justified}

When implementing Regional Trip Planning systems, not all transit agency
partners have equal financial and staffing resources. The regional
projects have significantly more difficulty when different GIS and
scheduling systems provide the data. There is an additional challenge of
coordinating all the stakeholders, both internally and externally. For
the project to be successful:

-   Each partner agency must have the necessary data and communications
    infrastructure in place;

-   Common standards should be established and adopted;

-   Additional resources are needed to resolve how to handle shared data
    features and integrate the various agency data sets. For example,
    the regional trip planning applications require interagency transfer
    locations, a common base transportation network, and regional
    consistency in naming and locating services, landmarks, street
    names, and other elements;

-   Operational rules and business processes need to be coordinated or
    defined further to make ITS systems work;

-   Agencies must be allowed to implement their portion of the regional
    system at different times, given their different capabilities and
    resources;

-   Agencies need to cooperate, be flexible, and assist each other;

> Memoranda of Understanding that address operating and system
> administration procedures, as well as other issues, should be executed
> and regularly updated among regional trip planning partners; and
>
> Internet and other automated tools are needed for the regional
> partners to upload and maintain the data they provide, such as
> schedules and service bulletins. The tools can lessen the level of
> effort needed to participate in a regional project and help ensure
> continued participation.

### 5.5.3 Maps and Networks Lessons Learned {#maps-and-networks-lessons-learned .Style-Heading-3-+-Justified}

The features and accuracy of the base map, including the street and
transportation network, are also critical to the success of many
traveler information systems. Having only one source map for the various
information systems saves development and

maintenance resources and improves accuracy.[^83]

### 5.5.4 Voice Recognition Lessons learned {#voice-recognition-lessons-learned .Style-Heading-3-+-Justified}

Although the voice recognition components of interactive voice response
systems have improved over time, transit agencies have discovered that
there are still significant problems that must be overcome before
implementations can be successful.[^84] Issues that have caused problems
for voice recognition software include the clarity of signals to and
from cell phones, background noise, speech accents, soft-spoken
customers, volume capabilities of the phone system, and the complexity
of the task and voice options. IVR with voice recognition in support of
trip planning systems that allow for a large set of complicated street
names can pose data development and performance challenges. Some
agencies suggested that the voice recognition component be implemented
last, after most of the other systems and data issues have been
resolved.

### 5.5.5 Real-Time Lag Lessons Learned {#real-time-lag-lessons-learned .Style-Heading-3-+-Justified}

The communication of the real-time position of the bus generally has a
lag that can pose problems for real-time next bus information systems. A
number of elements, such as those listed below, can affect the lag time:

> Polling rates for AVL systems;
>
> The capacity of the data radio channel for transmitting data; and
> []{.mark}
>
> The design of the system (i.e., what data are transmitted via what
> path between the vehicle, the center, and the distribution channel).

These elements and others can limit the timeliness and the accuracy of
estimated real-time bus arrival and departure times. The communications
lag is particularly frustrating for a passenger and customer service if
the lag results in a delayed report of a bus that has already departed a
stop.

In the future, an increasing number of transit agencies will be able to
employ GPS-based AVL that includes variable position reporting rates. As
vehicles' on-time status changes, especially as they approach a stop, as
determined either onboard or at the fixed end, they report their
position and speed more frequently. When on-time status is determined to
be relatively constant, and when far from a stop, reports are less
frequent. This minimizes real-time lag at critical times while avoiding
needless bandwidth utilization.

### 5.5.6 Communications Lessons Learned {#communications-lessons-learned .Style-Heading-3-+-Justified}

The type of communications systems used cannot only affect data lag time
issues, but can also impact the types and amount of data that can be
transmitted, the cost of the implementation and maintenance of the
communications infrastructure, and many other issues. This is especially
true for systems that communicate real-time system performance. For
additional information on the challenges and emerging technologies
pertaining to communications, see the Communications section of Chapter
2. A long-range plan for communications technologies and ITS
applications, particularly onboard the bus, is important for efficient
transmission of data.

### 5.5.7 Bus Stop Data Lessons Learned {#bus-stop-data-lessons-learned .Style-Heading-3-+-Justified}

Accurate bus stop data is critical for traveler information systems,
particularly next-bus and trip planning systems. In addition, a process
(ideally automated) must be in place to create "bus stop sequence" data.
The process must ensure that the proper sequencing of bus stops along a
route is known, handling issues such as "skip stops," inactive stops,
and stops on the far side of an intersection where a bus turns.[^85]

### 5.5.8 Floodgate Messages Lessons Learned {#floodgate-messages-lessons-learned .Style-Heading-3-+-Justified}

For 511 systems, when there are major incidents or events, agencies have
learned to use floodgate messages (one of the first messages that you
cannot skip), which shortens call durations significantly. Since 511
systems typically experience high call volume at specific peak times,
floodgate messages are one way to handle the peaks rather than
overbuilding the system to cover them.[^86]

### 5.5.9 Miscellaneous Lessons Learned {#miscellaneous-lessons-learned .Style-Heading-3-+-Justified}

-   Conduct limited field demonstrations first;

> Avoid the tendency to quickly buy systems. Instead, initiate all steps
> of a systems engineering approach. Do not skip steps such as the
> definition of key stakeholders, functional requirements definition,
> alternatives analysis, detailed requirements definition, development
> of a thorough testing and acceptance criteria plan, and development of
> an Operations and Maintenance Plan;
>
> Budget for the time and resources needed for systems engineering;
>
> Include all the key stakeholders early in the process. Many different
> parts of transit need to be involved in the projects, particularly in
> the data development and maintenance effort;
>
> Improve the customer's experience with the transit data, by having
> consistency between the names and abbreviations used on paper
> timetables, bus head signs, Web sites and other materials;
>
> Spend time getting the Internet interface right for the customers.
> Transit Web site guidelines are available from Volpe;
>
> Use standards where possible;

-   Anticipate future needs when building system requirements and have a
    far-sighted project architecture that is open and capable of
    expansion;

> Trip planning systems need to be fine-tuned and users need tips on how
> to use them most effectively; and
>
> Have a mechanism for customer feedback.

## 5.6 References {#references-3 .Style-Heading-2-+-Justified}

Coogan, Matthew A. "e-Transit: Electronic Business Strategies for Public
Transportation. Volume 4: Advanced Features of Transit Website.**"**
TCRP Report 84. Transportation Research Board, National Research
Council, 2003, 5 pp.
<http://transitweb.volpe.dot.gov/LinkRedirect.asp?NewURL=http://gulliver.trb.org/publications/tcrp/tcrp_rpt_84v4.pdf>.

Federal Transit Administration. "Guidance for Developing and Deploying
Real--Time Traveler Information Systems for Transit."
*FTA--OH--26--7017--2003--1* (2003), 143 pp.\
<http://ntl.bts.gov/lib/23000/23600/23663/RTTIS_Final.pdf>.

Radin, Sarah, David Jackson, David Rosner, and Sean Pierce. "Trip
Planning State of the Practice." Federal Transit Administration,
FTA-TRI-11-02.6, July 2002, 60 pp.

[www.itsdocs.fhwa.dot.gov//JPODOCS/REPTS_TE//13685.html](http://www.itsdocs.fhwa.dot.gov//JPODOCS/REPTS_TE//13685.html).

Raman, Mala, Carol Schweiger, etal. "Guidance for Developing and
Deploying Real-Time Traveler Information Systems for Transit." FTA
FTA-OH-26-7017-2003.01**,** April 2003, 139 pp.\
<http://transitweb.volpe.dot.gov/LinkRedirect.asp?NewURL=http://ntl.bts.gov/lib/23000/23600/23663/RTTIS_Final.pdf>.

Schweiger, Carol L. "Real-Time Bus Arrival Information Systems: A
Synthesis of Transit Practice 48.**"** Transportation Research Board,
National Research Council. Transit Cooperative Research Program, 2003,
61pp. \[Project J-7\]

<http://transitweb.volpe.dot.gov/LinkRedirect.asp?NewURL=http://www4.trb.org/trb/onlinepubs.nsf/>.

Volpe Transit Web US DOT publications:

> "[[Website Usability
> Guidelines]{.underline}](http://transitweb.volpe.dot.gov/guidelines/main.asp)
> for Transit Websites"
>
> Cunningham, Paul H., Joel A. Ogden, and David F. Wourms, "[Best
> Practices for LED Bus
> Signage](http://transitweb.volpe.dot.gov/BusSignage/main.asp) for
> Persons with Impairments." FTA-VA-26-7026-2003. January 1, 2004. 50
> pp.
>
> "Customer Preferences for Transit ATIS: A Research Study of Public
> Preferences for Transit Information."
>
> <http://transitweb.volpe.dot.gov/Introduction.asp>.

# Chapter 6 Transit Safety and Security

## 6.1 Introduction and Technology Overview {#introduction-and-technology-overview-3 .Style-Heading-2-+-Justified}

### 6.1.1 Transit Safety and Security {#transit-safety-and-security .Style-Heading-3-+-Justified}

For decades, public transit has used technology to improve both the
safety and the security of its operations to prevent or mitigate
intentional or unintentional incidents involving the well-being of
transit employees, customers, and physical assets. From a *safety*
perspective, technologies have long been used to help monitor the
operating status of engines, drive trains, brakes, wheels, and tires.
Video and other technologies used in and around transit facilities have
helped to monitor weather and other environmental conditions for safe
operations of rail and passenger terminal services.[^87] Use of such
technologies has certainly helped to reduce accidents and other
*unintentional* causes of harm to employees, customers, and physical
assets. From a *security* perspective, technologies such as radio
communications systems, video surveillance systems, automated vehicle
location (AVL) systems, and other advanced technologies, have helped
agencies to monitor situations onboard vehicles and at transit
facilities, thus improving prevention and response to *intentional* acts
of crime or violence. As described below, the advent of greatly improved
digital video and communications technologies has helped transit
agencies to significantly enhance both safety and security by providing
systems to guard against, and respond to, both unintentional and
intentional harm.

Central to designing and deploying technological solutions for safety
and security applications is transit's ability to employ or refine
existing ITS and information technology (IT) systems. Forward-looking
transit agencies are turning to existing IT technologies and standards
(e.g., Internet Protocol or IP, Extensible Markup Language or XML), as
well as off-the shelf-technologies to provide timely information to help
protect and secure the communities they serve. Agencies using real-time
information systems are assessing the possibility of applying Web-based
services architectures to rapidly deploy information such as traffic
routes and emergency bus schedules. Advanced sensors used in the
military to detect hidden bombs are now being further refined so they
can be used by transit and others to quickly and accurately scan people
and luggage. Additionally, broadband networks tying together land-based
and wireless technologies are being designed and installed around major
cities. New data visualization tools that can handle spatial and graphic
elements to analyze network traffic patterns may also be applied to
future incident response systems that integrate map data gathered from
Global Positioning Systems (GPS). Applications of these new innovations
in ITS and IT systems present the most exciting examples of the state of
the art in transit safety and security.

### 6.1.2 Increased Sense of Urgency {#increased-sense-of-urgency .Style-Heading-3-+-Justified}

After the terrorist attacks in New York City and Washington, DC on
September 11, 2001, there has been an increased sense of urgency within
the transit community to develop and deploy technologies to assist in
counter intelligence, infrastructure protection, emergency response, and
post-incidence recovery from intentional acts of violence against public
transit employees, customers, and physical assets. Furthermore, the
economic and social impacts of major domestic natural disasters such as
severe hurricanes underscored the criticality of establishing policies,
plans, and procedures for transit to operate in emergency response and
recovery mode.[^88]

In fact, since 9/11, data sharing has been a top priority at all levels
of government, as well as between government and business. However,
providing access to data from multiple systems has proven to be a
technological challenge. Poor regional coordination, tough data
management problems, and infrastructure limitations are complex issues
that will take time to implement. The much publicized failed attempts at
data sharing illustrated just how complex things can get when systems
have to be woven together and coordinated with social and local
community expectations.

Other challenges impeding the deployment of advanced technologies
include insufficient funding, deficient maintenance, and politics.
Because of these challenges, few, if any, transit agencies have
demonstrated, tested, or deployed much-needed technological systems such
as advanced bomb-detecting technologies or other passenger screening
systems. The ability to accurately detect chemical or biological agents
within transit facilities and vehicles is considered by experts to be
many years away and requires the expenditure of hundreds of millions of
dollars. In the interim, transit has increased security patrols, and
instituted better coordination and cooperation with law enforcement,
emergency medical teams, and fire departments.

Despite the slow progress, there have been some emerging cases where
transit personnel have convinced their governing boards to make
investments in advanced security technologies --- and the necessary
support systems, training, and maintenance programs --- that will help
make their agencies safer and more secure. Most of these
state-of-the-art systems involve two technologies: digital video and
broadband wireless Internet. Combined with rapidly increasing data
storage capabilities, these technologies give transit safety and
security personnel the ability to monitor high-resolution, real-time,
digital video from both vehicles and fixed facilities such as passenger
stations and maintenance yards. The ability to make a visual
confirmation of situational conditions provides a significant
improvement in the ability of safety and security personnel to
accurately assess an incident and deploy appropriate prevention,
mitigation and recovery responses. Furthermore, through cooperative
agreements with law enforcement, fire, and emergency medical teams,
transit personnel have demonstrated that it can expand its "view" of
systemwide operations to provide even greater geographic coverage.[^89]

How well transit responds to homeland security measures and
federal/state/local disasters depends in large part on the amount of
funding government and business are wi**l**ling to commit to
technologies that protect people and assets. In addition, for
technologies to truly advance transit safety and security, hardware and
data standards must be developed, tested, taught, and maintained.
Finally, as with most applications of technology, it is not the
technology itself that poses the biggest challenges; rather, the
greatest challenges lie in the policies, procedures, processes, and
attitudes of the people involved. Thus, as important as it is to be able
to procure and deploy the hardware and software for state-of-the-art
technologies, it is just as important to develop and maintain
interdepartmental and external relationships that involve stakeholders
from various transit departments and related outside organizations so
that use of the technologies can be optimized across political and legal
jurisdictional boundaries to truly serve regional areas and the nation
as a whole.

## 6.2 Onboard Safety and Security {#onboard-safety-and-security .Style-Heading-2-+-Justified}

### 6.2.1 Technology Description {#technology-description-13 .Style-Heading-3-+-Justified}

Central to most transit agencies' onboard safety and security systems
are voice communications and video assessment technologies.

#### 6.2.1.1 Voice Communications {#voice-communications .Style-Heading-4-+-Justified}

Radio communication between operating vehicles and command centers has
been a mainstay for public transit operations for decades.[^90] Having
voice contact enables vehicle operators to inform dispatchers of unusual
delays or emergencies in real time. However, the use of the technology
is limited by frequency bandwidth restrictions and a lack of
standardization across vendor products and jurisdictional
boundaries.[^91]

#### 6.2.1.2 Video Assessment Systems {#video-assessment-systems .Style-Heading-4-+-Justified}

Commonly referred to as video "surveillance" systems, the most basic
video assessment systems produce simple black-and-white images. These
images are scanned every few seconds from stationary installations
onboard buses or trains and then uploaded and archived when the vehicles
return to the agency. The most advanced systems produce full-color
digital video recordings that are transmitted in real time from
pan-tilt-zoom installations on transit vehicles via wireless broadband
local area networks (LANs) back to agency operations centers. These
systems are the "eyes" of transit management and provide important
real-time monitoring and archival documentation of onboard vehicle
incidents.

### 6.2.2 State of the Art {#state-of-the-art-14 .Style-Heading-3-+-Justified}

#### 6.2.2.1 Interoperable Radio Communications {#interoperable-radio-communications .Style-Heading-4-+-Justified}

There have been many regional, state, and federal efforts to achieve
radio voice communications interoperability between and among agencies
that operate large fleets of vehicles, such as police, fire, and
emergency medical teams, and operating agencies such as public
transit.[^92] Yet, to date, there still are no national standards for
radio interoperability. As a result, local first responders and public
transit are often left to use proprietary, noncompatible electronic
radios with nonstandardized data definitions and are unable to
communicate across agency or organizational boundaries during a crisis.
In addition, this lack of standardization results in inefficient
redundancies and an inability to leverage large radio infrastructure
investments such as transmission towers, electrical switches, and power
generation equipment. As a result, the state of the art of today's
"interoperable radio communications" cannot be considered "advanced."

There are, however, two exciting examples of emerging technology that
warrant attention. The first example is a "transit mobile broadband
communications" system that has been implemented in several metropolitan
areas, including Cedar Rapids, IA. By using a system of wireless
Internet access hubs and equipping transit vehicles with inexpensive
wireless modem cards, such systems can provide seamless Internet access
throughout a transit corridor. Thus, a virtually endless variety of data
and information packages can be communicated to and from vehicles within
the corridor. Deployment of such "broadband communications corridors"
may finally provide an interoperable platform for voice and data
communications previously not achievable by traditional radio systems.

The second example is the Capital Wireless Integrated Network (CapWIN)
program, a partnership between the states of Maryland and Virginia and
the District of Columbia to develop an interoperable first responder
data communication and information sharing network.[^93] The project
seeks to enable data interoperability for first responders wherever they
are. To achieve this vision, the CapWIN program has developed a unique
data sharing system and set of applications through the participation of
multiple state, local, and federal partners. The CapWIN system is
currently available free of charge to first responders across Maryland,
Virginia, and the District of Columbia, as well as federal agencies.
While these systems do not focus on transit, the methods and results of
CapWIN efforts are very similar to what would be needed in a transit
context.

#### 6.2.2.2 Video Assessment Systems {#video-assessment-systems-1 .Style-Heading-4-+-Justified}

While many transit systems use low-resolution black-and-white scanned
image technology, there are virtually no current installations of
sophisticated, digital, color video assessment systems onboard buses or
trains. The primary obstacle has been the lack of bandwidth to transmit
high-density digital video from moving vehicles.[^94] As improvements in
bandwidth technology are made, such applications are certain to be a
high priority for transit agencies.

## 6.3 Station/Facility Safety and Security {#stationfacility-safety-and-security .Style-Heading-2-+-Justified}

### 6.3.1 Technology Description {#technology-description-14 .Style-Heading-3-+-Justified}

Video assessment systems are the linchpin in most transit agencies'
station and facility safety and security systems because they have the
potential to tie together many other stand-alone aspects of safety and
security systems, such as fencing, barrier, lighting, access control,
sensor, control, and crisis management systems. For example, an
accidental fuel spill at a maintenance facility can be seen and
monitored on real-time video, providing transit safety personnel the
ability to quickly assess the appropriate type and level of emergency
and cleanup response. A security example would be software used with a
video monitor at the entrance of a rail tunnel that would trigger an
automated alarm that would alert security personnel to a vehicle or
persons engaged in unauthorized activity. Transit management can achieve
significant returns on most of its safety and security investments by
designing, deploying, testing, and training in the use and maintenance
of a video assessment system that leverages an agency's other safety and
security assets.

The primary advantage to video assessment systems is their ability to
record and archive information for real-time and archival use. For
example, video makes it possible to determine whether one or more
persons "piggybacked" off a single access card entry into a control
room, whether it was a human intruder or an animal breaching a fence at
a maintenance facility, or whether there are casualties resulting from a
chemical release on a station platform. Acting in stand-alone mode,
access control systems, fence alarms, and chemical detection sensors can
only provide minimal prevention and detection. Combining these systems
with video, however, significantly enhances their effectiveness.

Likewise, the importance of a robust communications network that can
enable broadband access to the Internet cannot be overemphasized. In
addition to ensuring sufficient bandwidth to transmit high-resolution
digital video, the network must also ensure that network load balancing
can be achieved efficiently. There are new tools available to
effectively monitor network loads,[^95] and attention should be given to
this critical aspect of network-based technologies to ensure optimum
performance of all technology components.

### 6.3.2 State of the Art {#state-of-the-art-15 .Style-Heading-3-+-Justified}

Current state-of-the-art intelligent video systems are those that make
digital video accessible from any PC or personal digital assistant (PDA)
using Internet access protocols. Access is gained by secure login made
through an established virtual private network (VPN) to ensure the best
network security available, while leveraging the broad coverage of the
Internet. Typically, no special hardware or software is required to view
and control the video network. Access to the system can be obtained with
a standard PC, an Internet Web browser, a virtual private network (VPN)
account to log in, and an authorized user name and password. Digital
video assessment systems that are Internet-based are easy to expand, and
performance quality and reliability will continue to improve as
broadband availability improves and data storage costs continue to
decline in the future. Once digital video is captured, software
applications can identify intruders, unattended baggage, unusual crowd
formations, etc. Software can also provide a means of integrating
information from chemical and biometric analytical tools.

What makes any video assessment system effective is a combination of
well-specified, deployed, and maintained technology, along with a body
of knowledgeable and engaged users. For example, the New Jersey Transit
(NJT) video assessment system is certainly technologically
"state-of-the-art," but what makes it truly effective is the
interdisciplinary, multi-agency, multijursidictional way in which it is
used. The functional requirements for the system were defined under the
direction of the NJT police chief, who worked closely with the head of
the Information Technology Department who, in turn, specified the
technical aspects of the system. The police chief culled requirements
not only from transit operations, but from strong working relationships
with the New Jersey State Police, Amtrak, New York City Metropolitan
Transportation Authority, and the Port Authority of New York and New
Jersey.

Now that the NJT video assessment system has been deployed, a suite of
software provides live and archived feeds that count customers, detect
dropped bags, and track intruders in secure areas such as tunnels and
bridges. The system also monitors no-parking areas and detects unusually
large crowds that might indicate some kind of problem. Live and archived
feeds are shared appropriately by NJT with all the other cooperating
agencies (as well as fire, law enforcement, and emergency medical teams)
to enhance multi-agency intelligence sharing and responsiveness to
incidents throughout the region's bus and rail networks.

Benefits to the agency beyond safety and security are significant. When
people know that incidents have been recorded, they are less inclined to
file a false claim against the agency, resulting in substantial savings
not only in claims losses and trial and litigation time and expense, but
in case processing and investigations as well. Customer service
complaints are also checked against video records to verify the accuracy
of the complaints. Additionally, maintenance can view video from a PC,
mobile phone, or PDA to determine how to prioritize sending crews out to
clear snow or debris.

## 6.4 Incident Response {#incident-response .Style-Heading-2-+-Justified}

### 6.4.1 Technology Description {#technology-description-15 .Style-Heading-3-+-Justified}

Incident response[^96] can be segmented into three broad categories:
detection/ assessment, response/evacuation, and communications.
Technologies that support these functions are described below.

#### 6.4.1.1 Detection/Assessment {#detectionassessment .Style-Heading-4-+-Justified}

There have been a few isolated attempts to develop applications that
detect chemical release at transit stations, including a significant
effort sponsored by the U.S. Department of Homeland Security called
PROTECT (see below). Another is a "puff portal" where air is circulated
around a passenger for 15 seconds and analyzed for explosive particles.
This latter technology is being tested at airports and may have
application at major rail stations in the future. Onboard panic alarms,
radio, and video systems also help with detection.

#### 6.4.1.2 Response/Evacuation {#responseevacuation .Style-Heading-4-+-Justified}

Computer Aided Dispatch (CAD) is a valuable tool in incident response,
particularly when supported by an effective Geographic Information
Systems (GIS).

For onboard and transit station facilities evacuations, electronic
signage and public address systems can help inform and instruct transit
passengers on safe egress from harm.

For area-wide evacuations, the primary focus of transit technology
efforts for public information and emergency evacuation has been related
to the nation's 511 Travel Information System.[^97] The Federal
Communications Commission (FCC) designated 511 as the national travel
information number in July 2000. The first 511 service was launched less
than a year later in northern Kentucky. By early 2005, twenty-five 511
systems had been launched with several more nearing deployment.

Many transit agencies participate in regional 511 planning and
deployment efforts. The degree of success is contingent upon the
agencies' ability to collect and organize their data and information
efficiently and effectively so that they can be shared with regional
partners. While the 511 systems are developed for general information
about travel services, having them in place with transit participation
effectively provides a communications platform upon which transit can
communicate with partner agencies and the general public under emergency
conditions as well. The Bay Area's 511 transit information Web site is
one of the best examples of a functioning technology that can be used as
a "platform" upon which an effective incident response strategy can be
built.[^98]

#### 6.4.1.3 Communications {#communications-2 .Style-Heading-4-+-Justified}

All transit agencies have radio systems to maintain communications
between agency dispatch centers and fleet and supervisory vehicles. Many
systems are stand-alone and do not allow for communications with law
enforcement, fire, or emergency medical teams from neighboring or
contiguous jurisdictions. In some instances, radio interoperability with
other agencies has been achieved where transit agencies operate as part
of a county administration.[^99] The lack of national radio
interoperability has resulted in a tenuous reliance on cell phone-based
communications, despite issues of lost signals between transmission
zones and switch capacity constraints during periods of high volume
calling.

### 6.4.2 State of the Art {#state-of-the-art-16 .Style-Heading-3-+-Justified}

#### 6.4.2.1 Detection {#detection .Style-Heading-4-+-Justified}

Significant research and development progress has been made by the
Program for Response Options and Technology Enhancements for
Chemical/Biological Terrorism (PROTECT). PROTECT is an operational
chemical agent detection and response system intended to significantly
decrease response time, which, in the event of a chemical attack, will
save human lives. The system includes detectors that sense chemical
agents, video for incident verification, a computer program to model the
spread of contamination in the subway, above-ground flow modeling for
dispersion of toxic materials from street vents and station exits, and
wireless communication for emergency responders.

PROTECT has been installed, tested, and placed in service in more than
five Washington Metropolitan Area Transit Authority (WMATA) subway
stations since 2003, and is being expanded. It is also currently
undergoing tests in Grand Central Station in New York City, at South
Street Station in Boston, MA, and in Baltimore, MD. Plans are also
underway to begin specifying a system for the Regional Transit Authority
(RTA) in Chicago. Although the system is limited to detecting chemicals,
research and development efforts are underway to integrate radioactivity
sensors to enable detection of "dirty bombs" in transit facilities.

The PROTECT effort has included robust testing under live conditions at
transit stations, and lessons learned have been well documented and
applied to subsequent test sites. Results to date indicate promise in
achieving the goals of the program, and applications at additional major
transportation terminals and stations are anticipated. Unfortunately,
the high cost of such systems, especially the integrated testing and
calibration of the hardware, software and procedural components will
place the technology out of the reach of most transit systems in the
near future. However, as more agencies procure the technology in the
future and the systems are upgraded, it is hoped that the costs and
risks associated with system deployment will decline.

#### 6.4.2.2 Response/Evacuation {#responseevacuation-1 .Style-Heading-4-+-Justified}

Technology currently plays only a minor role in the evacuation of
population groups subject to the effects of a major incident. Technology
use will increase as more people adopt the use of computers and handheld
devices, and as more transit agencies develop robust, real-time
information systems that can collect, assess, and transmit relevant
emergency evacuation information via information service providers to
remote kiosks and other transportation and emergency management control
centers.

#### 6.4.2.3 Communications {#communications-3 .Style-Heading-4-+-Justified}

As demonstrated not only by the 9/11 communications failures at the
World Trade Center (in which hundreds of firefighters were sent up into
the towers, even as evidence of the imminent collapse of the towers was
becoming known) but by the Hurricane Katrina and Hurricane Rita
evacuations as well, the most significant role technology can play in
incident response is to provide timely and reliable communications for
emergency responders, including transit. Given the lack of
interoperability standards in radio communications systems among
transit, law enforcement, fire, and medical response teams, the current
state of the art in transit incident response communications is a
tenuous reliance on ordinary cell phone technology.

## 6.5 Incident and Disaster Planning Support Systems {#incident-and-disaster-planning-support-systems .Style-Heading-2-+-Justified}

### 6.5.1 Technology Description {#technology-description-16 .Style-Heading-3-+-Justified}

The basic concept of incident and disaster support systems is a simple
one: provide a way for transit managers to access critical information
concerning their agency's assets, policies and procedures, regional
contacts, alternative scenario plans, and so on. In addition, safety and
security incident tracking and analysis can help planning and resource
allocation decision making.

Several transit agencies have used, or are considering using, software
packages that provide an automated platform for managing crises. These
incident and disaster support systems provide a way to collect and
organize data (e.g., resource lists, deployment updates, SOP
checklists), maps, photo and video images, and crisis management plans.
These support systems, which essentially are platforms for managing
large quantities of multimedia data and information, provide transit
agencies with a tool that can make critical incident and disaster
response management more efficient and effective.

There are dozens of software providers[^100] with products ranging in
scope and depth from basic database management of incident tracking,
emergency contact lists, and asset management, to more sophisticated,
customized features such as:

> Quick situation reports;
>
> Real-time weather tracking sources;
>
> Standard Operating Procedures (SOPs) integrated with emergency plans;
>
> Geographic Information Systems (GIS) map locations of incidents;
>
> Dashboard indicators of the real-time response capabilities of the
> organization in both tabular and graphical formats;
>
> Integrated chemical management that maps chemicals by location and
> links them to material data sheets; and
>
> Risk analysis tools for nuclear, biological, and chemical warfare and
> accidental industrial or transportation chemical releases.

### 6.5.2 State of the Art {#state-of-the-art-17 .Style-Heading-3-+-Justified}

There are many transit agencies and other governmental organizations
that are using or have tried some form of incident and disaster support
software. The benefits can be significant for the individual agencies,
to the extent that there is useful data and information to load into the
software package. However, the collection, management, and maintenance
of the data and information from multiple departments and agencies
require keen leadership and team-building skills, as well as significant
staff resources to ensure that the data and information are kept
up-to-date.

The performance of these systems often falls short of their true
potential since each agency typically purchases software that is
proprietary and not interoperable with those owned by other agencies;
nor are the databases or application profile interfaces standardized,
even within each agency. There are the occasional, well-executed,
customized software codes that are interesting, such as click-on icons
that call up windows containing live digital video feeds from remote
locations overlaid on a GIS map that indicate latitudes and longitudes
of the site and link directly into the emergency bus routing plan for
emergency evacuation. For the most part, however, the state of the art
falls short of the level of interoperability needed that would enable
the sharing of live and archived feeds from multiple departments or
agencies needed to make the system truly useful.

It is likely that Web-based hosting of such data will soon provide an
equipment and software platform for such systems to allow them to
realize their true potential. However, the results will still fall short
unless the agency can adequately populate the system with appropriate
data and information.

## 6.6 Challenges and Lessons Learned {#challenges-and-lessons-learned-10 .Style-Heading-2-+-Justified}

The major challenges and issues encountered in using ITS technologies
for safety and security onboard transit vehicles for transit facilities
include:

> Lack of interoperability between and among systems due to lack of
> equipment and data standards;
>
> Populating the systems with timely, accurate, and usable data and
> information requires keen leadership to engage regional partners in
> the effort. It also requires a sustained commitment to acquiring and
> maintaining the data and information so that they are available and
> reliable for managing incidents;
>
> Consistent use of address standards is vital for incident tracking and
> analysis;
>
> Analysis and geographic display of safety and security incident data
> is valuable in determining effective resource allocation (cameras,
> scarce security personnel, route and zone safety measures); and
>
> Having an overall plan that clearly identifies who does what, in what
> order, and under whose command, in the event of a major safety or
> security incident.

## 6.7 Agency/Vendor Examples  {#agencyvendor-examples .Style-Heading-2-+-Justified}

### 6.7.1 Video Assessment Systems---New Jersey Transit Corporation (NJT) {#video-assessment-systemsnew-jersey-transit-corporation-njt .Style-Heading-3-+-Justified}

The state of the art in station and facilities safety and security
technology is best illustrated at NJT, where an "intelligent video"
assessment system has been in operation since 2004.

The main technology elements of the NJT intelligent video system
include:

> More than a thousand cameras, some with pan-tilt-zoom features,
> installed throughout the entire state at virtually all NJT rail and
> park and ride stations;
>
> Digital video recorders located at various onsite facilities with
> enough storage capacity for at least 90 days of video;
>
> High-speed, wide area network providing real-time transmission of
> digital video so personnel with access rights can log on, view live or
> archived feed, select a length of footage not to be overwritten, or
> pull footage back onto the central network; and
>
> Software that enables automated, "intelligent" monitoring that
> triggers alarms for human assessment of the scene.

The safety and security benefits of the system are numerous. Streaming
digital video from over a thousand cameras located throughout the
state's rail and bus network allows NJT police to have "eyes" nearly
everywhere. Since the system is Internet-based, video can be monitored
and recorded by any first responder or intelligence/detective agency
personnel with proper access credentials from any computer or PDA with
an Internet browser. Fires, burglaries, assaults, vehicle accidents, and
acts of vandalism can all be viewed, recorded and archived for
subsequent investigations. With software applications that automatically
count passengers, identify intruders, or trigger alarms when baggage is
left unattended on a station platform, the richness of the data and
information obtained by the system is compelling enough to internal and
external stakeholders involved with safety and security that they are
very interested in participating as "engaged stakeholders" in the
refinement of existing uses and the development of new applications.

As described in Section 6.3.2 above, the success of the intelligent
video assessment system at NJT is due to the quality of the hardware and
software, as well as the engagement of internal and external
stakeholders in the output of the system. Achieving this level of
effectiveness requires managerial leadership to champion the endeavor,
and sufficient staff resources to specify and deploy the system. The
police chief and head of the Information Technology Department, with
strong support from the agency's executive director, were instrumental
in making the project a success.

### 6.7.2 Chemical Detection Systems --- WMATA {#chemical-detection-systems-wmata .Style-Heading-3-+-Justified}

The best example of the state of the art in chemical detection is at
WMATA, where the PROTECT system has been monitoring five rail stations
for chemicals likely to be used by terrorists against passengers and
employees.

The system consists of chemical sensors and video cameras that send
information to a control center for assessment and possible action. Live
feed is also sent to related fire departments, the Department of
Homeland Security, and to emergency operations centers in Arlington,
Montgomery County, and the District of Columbia. The objective is to
effectively identify chemical releases at a transit station to provide
early crisis management. When an alarm is triggered by the sensors, the
video cameras are programmed to pan-tilt-zoom in the direction of the
alarm to enable visual verification of an incident.

The PROTECT system was also located at the Rail Operations Center in an
attempt to leverage existing capital investments in computers,
communications, and power, as well as to enable close coordination in
the event of an incident. However, despite best efforts by both WMATA
and the contractor (Argonne National Laboratory), it was not possible to
leverage existing capital investments by WMATA in a significant manner
because of the complexities of deploying and testing the system while
rail operations were in service. Therefore, the system evolved as a
nearly stand-alone operation with its own cameras, servers, power
generation system, and communications cabling. Despite the redundancy,
the operational coordination aspects have proven to work well.

PROTECT has been thoroughly tested, and the equipment and software are
performing to specification. The sensors pick up suspicious odors and
send alarms to the control center and the video cameras pan-tilt-zoom to
the area where the odor was detected. From an IT infrastructure
efficiency and effectiveness perspective, the system does not degrade
the overall WMATA IT network. In addition, the video cameras help WMATA
fight ordinary crimes such as burglaries and assaults, and assist
firefighters by identifying the locations of smoke and flames.

The greatest challenge to successful deployment of the PROTECT system is
the development of policies and procedures on using the technology. For
example, who should get access codes to the information generated by the
system? What actions should personnel be authorized to take in the event
of an apparent attack? How does the agency deal with "false positives,"
as in the case where cleaning fluid had been spilled near a sensor?

In the next two to five years, WMATA will be expanding the PROTECT
system to detect radioactive material used to make so-called dirty
bombs. It will also be testing autonomous bio detection equipment that
will significantly reduce the time needed to get samples tested for
biological germs.

In summary, the technology exists for sensors and cameras to "see"
chemical, radioactive, and biological materials. The real question is
how will the agency be able to prevent perpetrators from setting them
off; or, if faced with a real attack, a detonation, or release of a
chemical or biological germ, what actions can and will be taken to
minimize casualties and speed recovery?

### 6.7.3 Transit Mobile Broadband Communications---Cedar Rapids, IA {#transit-mobile-broadband-communicationscedar-rapids-ia .Style-Heading-3-+-Justified}

One of the most exciting developments in transit ITS is the
implementation of a transit mobile broadband communications system in
Cedar Rapids, IA. In this application, the overlay of an ITS system with
extended features enabled by broadband at 1.5 mgbits per second onto a
mobile broadband technology enables the agency to communicate voice and
data transmission between vehicles (both fleet and supervisory) via a
combination of Ethernet and broadband wireless LAN. As described
earlier, this "enabling technology" provides seamless Internet access
throughout a transit corridor, and thus a virtually endless variety of
data and information packages can be communicated between and among the
vehicles within the corridor.

From the transit agency's perspective, the security-related benefits of
the broadband corridor include the ability to transmit live, streaming
video for continuously monitored security assessments and to tap into a
bus remotely to enable multimedia, control center-to-vehicle
communications during a crisis.

Other operating benefits of the system include passenger counting using
intelligent, video-based software; speedy information flows between the
vehicle and back-office administration; and location-based
communications to passengers concerning points of interest via high
resolution video. Video-based, automated passenger counting information
can also be monitored in real time by the control center to determine
whether or not to add an extra bus.

From the customer's perspective, the system provides a seamless
connection --- even during the vehicle's maximum traveling speed --- to
the rest of the world via the Internet using any handheld PDA or laptop
computer.

Future expansion of the system in Cedar Rapids beyond the initial test
corridor is highly likely, with an endless number of Internet
browser-based applications that can and will be made available to the
agency and its customers. As more municipalities around the nation begin
to deploy municipality-wide broadband Internet access systems for their
citizenry, browser-based services will become more prevalent. With the
advent of transit corridor broadband communications, citizens will still
be connected when they get on their bus and during their travels.

## 6.8 References {#references-4 .Style-Heading-2-+-Justified}

American Public Transportation Association. *Services and
Programs/Security resources Web page*.
[www.apta.com/services/security/](http://www.apta.com/services/security/).
Accessed on multiple dates between April 25 and September 9, 2005.

FTA's Safety and Security Web site, maintained by Volpe Transportation
Systems Center, Cambridge, MA. <http://transit-safety.volpe.dot.gov/>.
Accessed on multiple dates between April 25 and September 9, 2005.

Guerrero, Peter. *Challenges in Securing Public Transit.* Testimony by
General Accounting Office before the Subcommittee on Housing and
Transportation, Committee on Banking, Housing, and Urban Affairs, U.S.
Senate, September 18, 2002. 29 pp.
[www.gao.gov/new.items/d021075t.pdf](http://www.gao.gov/new.items/d021075t.pdf).
Accessed May 13, 2005.

Institute of Electrical and Electronic Engineers. "Telephone TV:
Broadcasting television to Mobile Phones." *Spectrum Online.*
[www.spectrum.ieee.org/WEBONLY/resource/jun05/0605ntv.html](http://www.spectrum.ieee.org/WEBONLY/resource/jun05/0605ntv.html).
Accessed September 4, 2005.

Institute of Electrical and Electronic Engineers. "South Korea Pushes
Mobile Broadband: The WiBro Scheme Advances." *Spectrum Online.*
[www.spectrum.ieee.org/WEBONLY/resource/sep05/0905nkor.html](http://www.spectrum.ieee.org/WEBONLY/resource/sep05/0905nkor.html).
Accessed September 4, 2005.

ITS America. *Public Transit Information Resource webpage*.
[www.itsa.org/new.nsf/vLookupForumIntro/Public+Transit!OpenDocument](http://www.itsa.org/new.nsf/vLookupForumIntro/Public+Transit!OpenDocument).
Accessed multiple dates between April 25 and September 9, 2005.

Jenkins, Brian Michael. *Protecting Public Surface Transportation
Against Terrorism and Serious Crime: An Executive Overview*. Mineta
Transportation Institute Report 01-14 (October 2001), College of
Business, San Jose State University, San Jose, CA. 38 pp.
<http://transweb.sjsu.edu/publications/TerrorismExOverv.pdf>. Accessed
May 14, 2005.

Littman, Todd. *Lessons from Katrina: What a Major Disaster Can Teach
Transportation Planners.* Victoria Transport Policy Institute. September
20, 2005.

Orbital Systems, Inc. *Transit Radio Communications Survey.*
[www.tms-online.com/projects_transit_index.html](http://www.tms-online.com/projects_transit_index.html).
Accessed September 6, 2005.

SAFECOM Program Office. U.S. Department of Homeland Security.
[www.dhs.gov/dhspublic/interapp/editorial/editorial_0339.xml](http://www.dhs.gov/dhspublic/interapp/editorial/editorial_0339.xml).
Accessed on September 4, 2005.

Schiavone, John. *Understanding and Applying Advanced On-Board
Electronics.* Transit Cooperative Research Program (TCRP) Report 43.
Transportation Research Board, National Research Council. 1999.

Seals, Jon. "All Linked Vendors." *Disaster Recovery Journal.*
[www.drj.com/vendor/drj5.html](http://www.drj.com/vendor/drj5.html).
Accessed September 8, 2005.

Texas, State of. *Radio Communications Interoperability Plan.*
[www.atcog.org/Tx%20Radio%20Communications%20Interoperability%20Plan.doc](http://www.atcog.org/Tx Radio Communications Interoperability Plan.doc).
Accessed September 3, 2005.

Transportation Research Board. National Research Council.
*Transportation Security: Surface Transportation references Web page.*
[www4.trb.org/trb/homepage.nsf/web/security](http://www4.trb.org/trb/homepage.nsf/web/security).

Transportation Research Board, "A Guide to Public Transportation
Security Resources." TCRP Research Results, Report 59 (May 2003). 20 pp.
<http://gulliver.trb.org/publications/tcrp/tcrp_rrd_59.pdf>. Accessed
May 5, 2005.

"Turning Transport On." *Intelligence and Warning America.*
[www.netscout.com/docs/reprints/NetScout_reprint_IWA_Turning_Transport_On.pdf](http://www.netscout.com/docs/reprints/NetScout_reprint_IWA_Turning_Transport_On.pdf)

Accessed June 28, 2005.

U.S. Government Accountability Office. *PROJECT SAFECOM: Key
Cross-Agency Emergency Communications Effort Requires Stronger
Collaboration.* April 2004.
[www.gao.gov/new.items/d04494.pdf](http://www.gao.gov/new.items/d04494.pdf).
Accessed on September 3, 2005.

ZDNet. Com. *Search: Mobile Broadband.*
[zdnet.search.com/search?q=mobile+broadband](http://zdnet.search.com/search?q=mobile+broadband).
Accessed September 8, 2005.

# Chapter 7 Transportation Demand Management

## 7.1 Introduction and Technology Overview  {#introduction-and-technology-overview-4 .Style-Heading-2-+-Justified}

As defined by the U.S. Department of Transportation, Transportation
Demand Management (TDM) is "any action or set of actions aimed at
reducing the impact of traffic by influencing people's travel
behavior."[^101] TDM, which includes all manner of public transit
operations and incentives, is the "big picture" strategic solution for
the day-to-day mobility problems that ITS was originally created to
address. In that big picture sense, the state of TDM implementation
itself defines the true "state-of-the-art" for ITS and transportation
management in general. The state-of-the-art in TDM defines the extent to
which transportation providers and travelers not only "do things right"
tactically, but "do the right things" strategically as well.

Public transit is central to TDM, and TDM strategies naturally yield
significant benefits for public transit. TDM strategies work hard to
improve public perception and cost effectiveness. Examples include
operations, information, and marketing strategies that increase transit
utilization; experimental routes and feeder services that open new
transit markets; and ridematch and telecommuting applications that
reduce peak vehicle requirements.

Unlike supply-side solutions that seek to temporarily reduce congestion
by adding capacity in reaction to existing or anticipated demand, a TDM
strategy seeks to permanently change the nature, magnitude, and
distribution of the demand for travel itself.[^102] While supply-side
solutions are focused on finding ways to move more vehicles, a TDM
strategy is focused on influencing traveler behavior so that existing
capacity can be used to accommodate more people.[^103] Where supply-side
solutions tend to involve small numbers of large projects aimed at
regional needs, a TDM strategy is more likely to involve large numbers
of relatively small projects tailored to local and individual
needs.[^104] TDM uses customized, even personalized, solutions to
proactively influence travel demand, mode choice, and trip time, both
pre-trip and en route. These innovative approaches are intended to
cost-effectively minimize transportation cost and time without
sacrificing personal mobility, thereby generating the greatest possible
return on investment from the regional transportation infrastructure.

Transportation professionals implement TDM by creating options for route
and mode choice by:

> Facilitating and influencing traveler decisions with respect to route
> choice, mode choice, and trip time;
>
> Encouraging greater vehicle occupancy (more people per car, van, or
> bus);
>
> Maintaining a balance between land development and transportation
> capacity;
>
> Strategically limiting new capacity to prevent unplanned induced
> demand; and
>
> Encouraging land development policies that minimize the underlying
> need for travel in the first place. [^105]

In addition, TDM efforts have targeted parking policies and practices
pertaining to parking availability, management, and costs.

The mission of ITS technology in supporting TDM is to generate and
communicate management and control strategies that reduce the number of
individuals who choose to drive alone, increase the use of high
occupancy vehicles and public transit, and provide a variety of mobility
options for those who wish to travel in a more efficient manner (i.e.,
during non-peak periods).[^106] The National ITS Architecture lists two
major functions for TDM, which are (1) Increase Efficiency of
Transportation System and (2) Provide Wide Variety of Mobility
Options.[^107] Most transportation professionals also recognize an
important third function, (3) Avoid Future Congestion.[^108]

The first two of these ITS functions are supported by such conventional
ITS applications as ramp metering, congestion pricing, high speed toll
collection, high occupancy vehicle (HOV) lane management, multimodal
traveler information, transit signal priority, highway advisory radio
(HAR), and variable message signs (VMS). Also included are less
conventional ITS applications such as pedestrian signal priority,
regional parking management, dynamic rideshare, multimodal service
coordination, and transportation alternatives marketing.

The third function, avoid future congestion, is supported by some of the
more strategic ITS applications such as the ITS data warehouse and
advanced travel demand modeling, as well as by transit incentive
programs and various transportation avoidance technologies unrelated to
ITS per se, such as the virtual office, telecommuting, and online
shopping. Avoiding future congestion is also supported by a variety of
nontechnical (i.e., legislative) growth management tools designed to
ensure a healthy balance between transportation demand and
transportation capacity.[^109]

Technologies used in this third functional area certainly influence
transportation demand. However, this report will not address them in
depth because the technologies are more likely to be systems and
programs that employers and retailers use to leverage the communications
capabilities of the Internet, or database tools that support policy
makers at a government level, rather than specific ITS technologies that
can be controlled or operated by a public transit agency.  

Specific ITS examples of TDM technologies and application examples
relevant to public transit include:

> Internet (for itinerary planning, registration and activation,
> information dissemination, and inter and intra-agency communications);
>
> Computer Modeling (for planning and decision support);
>
> Data Warehousing (for planning and decision support);
>
> Computer Networking (for system integration and inter and intra-agency
> communications);
>
> Personal Digital Assistants (PDAs) (for pedestrian location and
> traveler information dissemination);
>
> Machine Vision (for parking management);
>
> Dedicated Short Range Communication (DSRC) (for use of electronic toll
> tag equipped vehicles as roadway performance probes);
>
> Variable Message Signs (VMS) (for dissemination of modal travel times,
> parking availability, and time of next transit departure);
>
> Highway Advisory Radio (HAR) (for dissemination of modal travel times,
> parking availability, and time of next transit departure);
>
> Electronic Payment (for ease of access to transit, itinerary
> activation, and verification of specific need for connection
> protection);
>
> Transit Advisory Radio (for dissemination of real-time status and
> parking information);
>
> Interactive Voice Response (IVR) telephone (for itinerary planning,
> registration and activation, and personalized information
> dissemination);
>
> Voice Recognition (for ease of access to transit information);
>
> Infrared Sensing (for sidewalk/crosswalk occupancy detection);
>
> 511 Traveler Information Portals and Services (for improved access to
> information);
>
> Automatic Vehicle Location (AVL) (for service status and real-time
> identification of needs for connection protection);
>
> Cellular Telephone (for traveler communication);
>
> Mobile Data Terminals (for trip assignments, route guidance, and
> service coordination operating instructions);
>
> Transit Signal Priority (TSP);
>
> Integrated Corridor Management (ICM);
>
> XM Satellite Radio (for information dissemination);
>
> Geographical Information Systems (GIS) (for itinerary planning,
> information presentation, and decision support); and
>
> Data Interface Standards and Protocol Converters (gateways) (to enable
> inter- and intra-agency data exchange).

Other non-ITS solutions that have demonstrated significant TDM benefits
include:

> Car-sharing where employers maintain (or subscribe to) a pool of
> vehicles to be used for business travel, thereby eliminating the
> necessity for employees to drive to work merely to have a vehicle
> available for work-related travel[^110];
>
> Parking cash out where employers who provide free parking offer the
> cash equivalent of the parking subsidy to employees who do not drive
> to work[^111];
>
> Employer-provided bus passes and bicycle amenities that allow
> employers to reduce single occupant vehicle travel while
> simultaneously saving money on parking lot operation and
> maintenance;[^112]
>
> Alternative work hours;[^113]
>
> Trip reduction ordinances;[^114]
>
> Negotiated demand management agreements;[^115]
>
> Transit-friendly site design to minimize traffic;[^116]
>
> Auto restricted zones;[^117]
>
> Growth management ordinances;[^118]
>
> Home office/telecommuting;
>
> Feeder services;
>
> Shuttles;
>
> Parking management ordinances;
>
> Multiple use zoning ordinances; and
>
> Transit tax benefit programs (e.g., TransitCheck).[^119]

The distinction between transit-related TDM and everyday transit
operations is a fine one. For example, offering attractive and reliable
transit headways and travel times is a basic tenet of everyday transit
operations; it is also an enabling strategy for TDM. Effective marketing
of transit services is an everyday business reality; it also is an
element of TDM when influencing mode shifts from personal vehicles to
transit. Fleet management and operations supervision is another everyday
transit occurrence; it too becomes TDM when coordinated to enhance
service and/or provide seamless connections across modes. With respect
to transit, therefore, TDM is perhaps best characterized simply as
"advanced transit operations and marketing."

For purposes of this report, advanced transit operations and marketing
technologies applicable to ITS Transportation Demand Management have
been divided into three major categories:[^120]

> Dynamic Ridesharing;
>
> Automated Service Coordination; and
>
> Multimodal Transportation Management Centers.

Concerning state of the art, little has changed with respect to ITS
transportation demand management since the last State of the Art Report
(Update 2000) was published. The sites listed at that time essentially
retain that distinction today.

## 7.2 Dynamic Ridesharing  {#dynamic-ridesharing .Style-Heading-2-+-Justified}

### 7.2.1 Technology Description {#technology-description-17 .Style-Heading-3-+-Justified}

Dynamic ridesharing[^121] services can run the gamut of technical
complexity from manually operated call centers to fully automated,
Internet-based ridematch[^122] applications, and from personal
automobiles to fully automated personal rapid transit (PRT).[^123]

In its ultimate form Dynamic Rideshare is essentially a low-cost
paratansit service that provides a means by which two or more travelers
can be joined in real time with others headed to, or past, the same
locale with taxi like responsiveness.[^124] The rideshare trip may start
or end at an initial origin, a final destination, a transit stop, or an
intermediate rideshare transfer point. It could also involve private
automobiles, vanpools, paratransit vehicles, boats, and even light
aircraft. Most common at present, however, are subscription
ridematch[^125] and shared paratransit services that use private
carpools, private or corporate vanpools, and government-funded
paratransit vehicles.

Subscription ridematch services are administered by hundreds of public
and private Transportation Management Associations (TMAs) throughout the
U.S., as well as by many state DOTs. Subscription ridematch services
allow travelers (usually commuters) to register themselves as
passengers, drivers, or both, and then match prospective drivers and
passengers having common travel times, preferences, origins, and
destinations. They are often supported by corporate sponsors who benefit
from a reduction in required parking at their facilities. Most sponsored
ridematch services also offer a guaranteed ride home in case of
emergencies.

Shared paratransit services are typically operated by government
entities (either in- house or through a contracted provider) that
provide curbside pickup for multiple riders on preplanned routes that
are "dynamically" programmed the day before. This type of next-day
rideshare has found widespread use in satisfying the transportation
needs of state and federal welfare, Head Start, disabled, and special
needs programs throughout the U.S. They may also serve as feeder
services for local transit facilities.

Obviously, the greater the number of travelers that can be carried in a
given vehicle on a given trip without compromising quality of service,
the more efficient and effective the rideshare operation becomes. One
relatively recent innovation that has been successful in increasing
capacity utilization for next-day rideshare is the merging of
conventional subsidized paratransit services with full-fare subscription
services to provide a guaranteed ride for nonsubsidized travelers. The
idea is that if a vacancy exists on a subsidized paratransit vehicle,
then it makes perfect sense to pick up a full-fare passenger or two (or
six) along the way. Since the trip will run regardless, it may as well
run with more passengers. Subscription riders in Massachusetts enjoy a
high degree of satisfaction with the reliability, comfort, and
convenience of the merged service; so much so that the subscription
service must be managed to avoid oversubscribing spare paratransit
capacity.

Proposed advanced versions of dynamic ridesharing also include Personal
Rapid Transit (PRT)[^126] and Autonomous Dial a Ride Transit (ADART).
PRT is a theoretically highly efficient transport method that offers
unscheduled on-demand, nonstop transportation between any two points on
an interlaced network of specially built guideways separate from
existing roadways. It uses small (1-6 people) cars on mathematically
optimized point-to-point trajectories. ADART is a proposed method of
dispatching and routing transit vehicles over the existing roadway
network in real time that is theoretically more efficient than operating
a conventional fixed-route transit line with extremely low ridership (as
is often the case on mandated routes). Development projects are
currently underway in both areas, including a partial ADART
implementation in Corpus Christi, TX. However, fully functional and
fully operational examples in revenue service do not yet exist in the
U.S.

### 7.2.2 State of the Art {#state-of-the-art-18 .Style-Heading-3-+-Justified}

"Static" ridesharing and ride matching services have been in operation
since before the 1970s. The current state of the art has achieved "next
day" responsiveness (i.e., pairing riders with transportation providers
on a flexible day-by-day basis), but true "dynamic" ride matching,
(i.e., pairing riders with hosts in real time) has not yet been
successfully implemented in the U.S.

State-of-the-art paratransit ridesharing services are currently
distinguished by such features as:

> Automatic Web-based user registration;
>
> Automatic verification of trip eligibility (through integration with
> the agency's automated itinerary planning tool and eligibility
> databases);
>
> Next-day service;
>
> Automatic verification of service delivery (typically using coded
> subscriber ID cards and onboard card readers);
>
> Innovative use of supplemental subscription services to reduce
> subsidies;
>
> Dynamic allocation of individual trips to lowest cost operators on a
> day-to- day basis;
>
> Partnering (providing startup vehicles, umbrella insurance,
> communications, and administrative services) to encourage small
> operator participation; and
>
> Rigorous quality inspection and quality control to proactively ensure
> reliable service from contracted providers.

State-of-the-art sponsored carpool and vanpool ridematching services are
currently distinguished by such features as:

> Automatic Web-based user registration;
>
> Guaranteed ride home;
>
> Automated quality control surveys; and
>
> Automatic verification and purging of inactive participants.

Examples and characteristics of state-of-the-art dynamic ridesharing and
ridematching deployments found in transit include:

> Montachusetts Area Regional Transit, Fitchburg, MA
>
> System allows management of transportation brokerage for 75% of the
> state (most of Massachusetts except for Cape Cod and the Boston
> Metropolitan Area).
>
> Provides 11,500 trips per day with over 150 vendors and 600
> vehicles.[^127]
>
> Coordinates with commuter rail and intercity buses, and provides
> feeder services and parking.
>
> Working toward utilization of commuter rail for long-haul trips, using
> paratransit for relatively short distance carriage at origin and
> destination only.
>
> Conventional paratransit was merged with full-fare subscription
> service, which delivered an operating cost reduction of 60% with no
> impact on quality of service.
>
> Subscription service is especially popular for transporting young
> children to schools where conventional fixed-route transit typically
> involves multiple transfers or extended walking distances.
>
> MTA, Los Angeles, CA.
>
> Automatic paratransit eligibility verification.
>
> Automatic paratransit service delivery verification.
>
> New Jersey Department of Transportation, Trenton, NJ
>
> DOT-sponsored portal to Transportation Management Associations
> statewide
> ([[www.njcommuter.com]{.underline}](http://www.njcommuter.com/)).
>
> Statewide ridematching service.

### 7.2.3 Emerging Trends {#emerging-trends-10 .Style-Heading-3-+-Justified}

As vendors have developed more capable flex routing systems, and more
and more operators have equipped their vehicles with various forms of
communications and location tracking technologies, the lead time
required for trip requests continues to drop. Additionally, a growing
number of states are taking advantage of Internet technology to
facilitate statewide ridematching. In Corpus Christi, TX, where a
simplified partially autonomous dial-a-ride transit (ADART)
implementation is currently operational, progress continues toward
development of a fully functional ADART service designed to replace
underutilized fixed-route transit services with paratransit vehicles
dynamically scheduled in real time.[^128] Perhaps the most dramatic
development, however, is the certification in the United Kingdom of what
may become the world's first economically viable personal rapid transit
(PRT) application, due to begin pilot implementation at London's
Heathrow Airport later this year.

## 7.3 Automated Service Coordination  {#automated-service-coordination .Style-Heading-2-+-Justified}

### 7.3.1 Technology Description {#technology-description-18 .Style-Heading-3-+-Justified}

Automated Service Coordination refers to advanced transit operations
technologies, policies, and procedures designed to guarantee or
"protect" passenger transfers between the various vehicles and services
that may comprise a fully linked trip. In this usage, it is also
sometimes referred to as "automatic connection protection." A second
usage of the term applies to automatic headway coordination among two or
more different service providers along a common operating corridor.

Service coordination could occur between different vehicles of the same
mode, different modes, different agencies, and even different sectors of
the transportation industry. Supported transfers could include
connections between bus, rail, paratransit, ferry, rapid transit,
vanpool, taxi, commercial airline, and others. Even the connections from
pedestrian segments of the journey might be conditionally protected as
well (i.e., when PDAs and cell phones become more universally GPS
enabled), especially in areas where headways are significantly long.

Scheduled connections are planned at a policy level (where schedulers
design planned connections into the service) and executed at the
operational level (where dispatchers ensure that vehicles do not depart
from a planned connection point until their connecting trips have
arrived). Scheduled connections may be protected unconditionally as a
matter of agency policy, or conditionally as part of managed strategy to
optimize service quality and effectiveness on a trip by trip basis.

Automatic Service Coordination systems use ITS technologies such as AVL,
electronic fare collection, decision support systems, and mobile data
terminals to:

> Identify and/or confirm the existence of a desired transfer;
>
> Identify the need for coordination and intervention;
>
> Weigh the operating and passenger impacts --- both immediate impacts
> and likely downstream impacts --- of delaying or not delaying,
> expressing, or rerouting one vehicle to protect a planned connection
> with another;
>
> Communicate coordination requests to the agencies and vehicles
> involved;
>
> Receive confirmation that coordination will or will not be provided;
>
> Effect, facilitate, and monitor coordination;
>
> Provide notice to affected passengers as to whether their planned
> connection will or will not be honored and, if not, how long they
> should expect to wait for the next connection to their planned
> destination; and
>
> Evaluate overall effectiveness of connection protection actions (or
> inactions) taken.

Different implementers have used different methods for identifying and
confirming the existence of a desired transfer. In some cases, the need
for connection protection at a given transfer point is simply assumed
based on historical data or anecdotal observation.[^129] In others, a
vehicle operator manually initiates connection protection for a specific
trip based on a specific request from a specific passenger.[^130] In yet
other cases, in airline transportation, for example, service
coordination is tied to confirmed traveler itineraries.

One passenger information and customer resource management technology
common in airline transportation, and just now being considered for
public transit, is Itinerary Tracking, which also has promise for
identifying specific connections that may need to be protected on a
given day. Itinerary Tracking allows individual travelers to register
individual itineraries (via Internet or telephone), determines how known
delays and incidents are likely to affect each individual itinerary, and
generates customized real-time status and connection information for
each individual registered customer. The same registered itinerary that
drives the Itinerary Tracking application can also be used to identify
specific connections that may need to be protected. In addition, a
properly integrated electronic fare collection application offers yet
another opportunity for real-time confirmation that a given transfer may
need to be protected. To date, however, there are no reports of agencies
having actually tied a fare collection or itinerary tracking system to a
service coordination function to automatically identify and confirm a
specific need for connection protection on a specific trip.

### 7.3.2 State of the Art {#state-of-the-art-19 .Style-Heading-3-+-Justified}

Automated Service Coordination for public transit is still in its
infancy in the U.S. Unconditional connection protection is commonplace,
especially for commuter rail,[^131] while conditional protection is not.
Current systems do operate in real time using actual vehicle location
information, but instead use relatively simplistic decision- support
tools for determining the method and desirability of intervention to
protect a particular connection. No one implementation has yet pulled
together a complete, fully optimized package --- from identification,
through confirmation, evaluation, response, and followup --- and there
are no reports of any application that has attempted to automatically
protect connections between services operated by two or more different
agencies.[^132]

Systems deployed to date have met with varying degrees of success. While
passengers and operators do find value in Automated Service Coordination
technology, there are a number of common complaints. The most common
complaints are:

> That vehicles are sometimes held unnecessarily to protect planned
> connections that no passengers actually intend to use on the specific
> trip in question;
>
> That vehicles are sometimes prematurely instructed to delay departure
> from an upcoming transfer point when in fact the connecting vehicle
> will actually arrive on time; and
>
> The act of holding a vehicle to protect a connection at one location
> can often generate additional missed connections further downstream if
> done without proper consideration for the "big picture," especially
> where the slack in scheduled running times is insufficient to
> accommodate minor delays.

State-of-the-art Automated Service Coordination systems are currently
distinguished by such features as:

> Real-time identification of specific needs for intervention to protect
> planned connections; and
>
> Real-time delivery of connection protection instructions to affected
> vehicles.

Additionally, several transit agencies have implemented auto-dial or
e-mail notification capability to alert subscribing customers of service
disruptions and delays relevant to their usual itineraries.

Examples and features of state-of-the-art automated service coordination
deployments found in transit include:

> Utah Transit Authority, Salt Lake City, UT
>
> 600 vehicles equipped.[^133]
>
> Connections protected for transfers from light rail to bus.
>
> Specific target locations are selected based on expected transfer
> points.
>
> No real-time confirmation of numbers of passengers actually intending
> to transfer.
>
> Ann Arbor Transit Authority, Ann Arbor, MI
>
> 91 vehicles equipped.[^134]
>
> Manual initiation of connection protection by bus operator in response
> to specific requests from passengers.

### 7.3.3 Emerging Trends {#emerging-trends-11 .Style-Heading-3-+-Justified}

Decision-support systems used to determine the desirability of providing
connection protection in a given case are getting "smarter" with each
new implementation, and ties to automatic passenger counting (APC)
systems to aid in determining the actual impact of providing protection
(or not) are becoming more common. The next generation of these tools is
expected to include:

> Consideration of effective headway in determining whether or not
> intervention is actually necessary, and which vehicle's schedule
> should be modified (i.e., that of the vehicle being transferred to, or
> that of the vehicle being transferred from), and what form that
> modification should take;
>
> Consideration for downstream impacts of intervention at a given
> location;
>
> Consideration for numbers of passengers likely to be impacted by
> protecting or not protecting a given connection based on historical or
> APC ridership data;
>
> Cost-based optimization based on total passenger-minutes of delay,
> including additional waiting time for the next trip if the connection
> will not be protected; and
>
> Real-time identification and verification of the need to protect a
> specific connection based on electronic fare collection and/or
> itinerary tracking data.

## 7.4 Multimodal Transportation Management Centers  {#multimodal-transportation-management-centers .Style-Heading-2-+-Justified}

### 7.4.1 Technology Description {#technology-description-19 .Style-Heading-3-+-Justified}

A Multimodal Transportation Management Center refers to a collection of
traffic and transit operations centers that have been linked together to
facilitate optimization of regional network performance across multiple
transportation modes. Cooperating modes could include highway, bus,
rail, intermodal freight, and ferry. Cooperating agencies could include
transit operators, freight terminals, highway operators, public safety
organizations, ferry operators, parking operators, airport operators,
and bridge and tunnel operators. Cooperating centers could be physically
co-located, or merely electronically linked.

Multimodal transportation management seeks to transcend institutional
boundaries between the typically distinct, often sub-optimized fields of
transit management, traffic management, parking management, and incident
management to provide a more efficient regional transportation network,
and a less costly, less frustrating travel experience for commercial
shippers and the traveling public alike.

While the initial focus of a regional management system may be limited
to incident management alone, important as it is, much more can be
accomplished as parking and transit operations are factored into the
mix. Integration of parking management will enable transportation
agencies to inform travelers of not only where available capacity
exists, but equally important, when that capacity is expected to be
exhausted and whether there will be available capacity by the time the
motorist arrives.

Multimodal Transportation Management technologies include:

> Variable Message Signs;
>
> Electronic Toll Collection;
>
> Freeway Ramp Metering;
>
> Transit Signal Priority;
>
> Ramp Meter Bypass;
>
> Interagency Data Exchange;
>
> Video Surveillance;
>
> Video Data Exchange;
>
> Roadway Performance Monitoring;
>
> Automatic Vehicle Location;
>
> Electronic Payment;
>
> Machine Vision;
>
> Wireless Communications;
>
> Internet;
>
> Cellular 511;
>
> Highway Advisory Radio;
>
> Electronic Vehicle Identification;
>
> XM Satellite Radio; and
>
> Decision Support Systems.

Multimodal transportation management centers use these technologies to
monitor highway and transit performance to detect incidents and
congested conditions, notify affected agencies, identify available
assets, coordinate a unified response, and track results. The
distinctive element of multimodal transportation management, as opposed
to traffic, transit, parking, or incident management alone, is that the
identification of available assets and coordination of a unified
response is carried out in a cooperative manner by all the agencies
involved. Applications include:

> Data from multiple sources can be integrated automatically to speed
> detection and confirmation of incidents;
>
> Incident response assets of different agencies can be operationally
> pooled to speed incident confirmation and response;
>
> Assets from multiple agencies can be operationally integrated to
> provide coordinated regional disaster response;
>
> Transit information displays can be used to quickly disseminate Amber
> Alert missing persons information throughout the region;
>
> When a traffic incident reduces highway capacity, affected transit
> operators can be quickly notified, and viable alternative routes and
> available transit services can be quickly identified and relayed to
> motorists via variable message signs and highway advisory radio;
>
> Planned disruptions and events such as construction activities can be
> coordinated across multiple modes and agencies to prevent undue impact
> on the traveling public;
>
> Differences in route segment speeds or travel times for different
> routes and modes can be clearly illustrated on integrated regional
> maps in real time to allow travelers to make informed mode and route
> choice decisions;
>
> When parking areas downtown are full, motorists can be quickly
> directed to suitable park and ride facilities with known available
> capacity;
>
> Where roadways lack dedicated performance monitoring equipment,
> transit and commercial fleet operators can fill these information gaps
> using AVL-equipped vehicles as autonomous probes to measure and report
> roadway performance;
>
> When unexpected icing or other adverse conditions are detected at a
> specific location, transit agencies and trucking operators can be
> quickly notified and drivers warned appropriately;
>
> When transit vehicles are running behind schedule, traffic signals can
> be instructed to provide conditional priority;
>
> When a large platoon of vehicles is exiting a rail park and ride
> facility following arrival of a train, traffic signal timing can be
> proactively adjusted to optimize roadway performance; and
>
> When movement of a train will interfere with planned traffic flows,
> traffic signal timing can be dynamically coordinated with train speed
> to minimize unnecessary impacts on signal coordination.

### 7.4.2 State of the Art {#state-of-the-art-20 .Style-Heading-3-+-Justified}

Like "transportation management," the phrase "multimodal transportation
management" has come into common usage in contexts that fall far short
of its original intent. A quick search of the Internet will indicate
that nearly every state has something they call a "Multimodal
Transportation Management System," yet few if any have something that
can perform the kinds of operations described above. Although several
very promising, very successful applications do exist, much work still
remains.

In general, present-day "multimodal transportation management centers"
are at best actually more appropriately termed "multimodal
transportation information portals," entities that serve the valuable
purpose of relaying reported incident information to affected agencies
but are not equipped or staffed to support the close coordination
required to continually optimize regional network performance on a day
by day, minute by minute basis.

One very notable exception is TranStar, the transportation and emergency
management center for the greater Houston, TX, region. TranStar combines
traffic, transit, and emergency planning and management under a single
overall operating entity.[^135] Even in an operation as advanced as
TranStar, however, there is room to add parking management and rail
coordination to the list of transportation issues still to be addressed.

At present, parking management is still very much an evolving piece of
the puzzle. Concern about parking availability at rail stations and park
and ride lots may be all it takes to prevent motorists from trying
public transit. The ability to acquire and display real-time parking
information at an individual lot is relatively common throughout the
country.[^136] Collection and integration of parking information from
multiple lots for regional parking management, however, is not.

Currently, notwithstanding localized implementations at some national
parks and theme parks, no truly regional deployments of real-time
regional parking information systems have been reported in the U.S. The
current state-of-the-art in regional parking information systems that
have actually been successfully deployed in the U.S. appears to be
limited to the provision of static lot capacity information only.

Another area that is still evolving is that of integrated information
display for support of the pre-trip mode and route choice decision.
Integrated display of historical transit and highway performance and
reliability on a single regional map has not yet been attempted in the
U.S.

State-of-the-art multimodal transportation management is currently
distinguished by such features as:

> Static regional parking information;
>
> Use of AVL-equipped buses as probes for roadway performance monitoring
> on arterial roadways;
>
> Use of electronic toll-tags for roadway performance monitoring on
> freeways;
>
> Transit signal priority;
>
> Integrated incident detection, verification and response;
>
> Integrated weather and roadway condition reporting;
>
> Integrated construction and event planning;
>
> Integrated flow mapping and travel time calculation;
>
> Links to regional real-time transit status;
>
> Regional itinerary planning;
>
> Shared real-time video;
>
> Multilingual information; and
>
> Wireless information access.

Examples and features of transit related state-of-the-art multimodal
transportation management centers include:

> Houston TranStar, Houston, TX
>
> Co-located --- physical center
>
> Four agencies
>
> 300 miles of fiber optic cable
>
> 150 dynamic message signs
>
> 1,600 buses
>
> 18 light rail vehicles
>
> 40 roadway weather information stations
>
> 100 miles of high occupancy vehicle (HOV) lanes
>
> 350 video surveillance cameras
>
> 12 highway advisory radio (HAR) sites
>
> 200 miles of automatic vehicle identification (AVI toll tag) roadway
> monitoring
>
> Regional incident management system
>
> Rail crossing monitoring system
>
> Freeway interchange truck rollover warning system
>
> Los Angeles County Metropolitan Transportation Authority, Los Angeles,
> CA
>
> Advanced Transportation Management System provides infrastructure for
> planned multimodal transportation management and support to ongoing
> efforts toward regional traffic, transit, and incident
> management.[^137]
>
> Oregon Department of Transportation[^138]
>
> Integrated roadway status, weather, and construction information.
>
> Statewide rideshare portal.
>
> Statewide links to transit schedules (no itinerary planning).
>
> Links to adjoining states' information portals.
>
> Washington State Department of Transportation[^139]
>
> Real-time statewide video images.
>
> Real-time flow maps and travel times.
>
> Links to real-time transit status.
>
> Statewide links to transit itinerary planning tools.
>
> Regional Transportation District, Denver, CO[^140]
>
> Real-time bus and rail information.
>
> Regional park and ride parking capacities (static information).
>
> Itinerary planning.
>
> Internet, PDA, and cell phone accessible.
>
> Multilingual (English, Spanish, Italian, French).
>
> TDM initiatives.
>
> TRANSCOM, Jersey City, NJ
>
> Tristate multimodal transportation information portal for the New York
> metropolitan area.
>
> Hybrid architecture --- virtual center with physical hub.
>
> 16 agencies.
>
> Roadway performance monitoring using electronic toll tag readers.
>
> Interagency regional video network.
>
> Real-time regional traffic conditions.
>
> Near-real-time regional transit conditions.
>
> Regional itinerary planning.

### 7.4.3 Emerging Trends {#emerging-trends-12 .Style-Heading-3-+-Justified}

Prototype demonstration projects for real-time public transit parking
information systems have been initiated by the RTA in Chicago[^141] and
in Montgomery County, MD. If successful, corridor demonstrations such as
these may pave the way for U.S. deployments of real-time regional
parking information systems.

## 7.5 Challenges and Lessons Learned  {#challenges-and-lessons-learned-11 .Style-Heading-2-+-Justified}

### 7.5.1 Dynamic Rideshare Lessons Learned {#dynamic-rideshare-lessons-learned .Style-Heading-3-+-Justified}

Paratransit services traditionally require greater operating subsidies
than other transit services, but integration of paratransit with
supplemental subscription services that fill underutilized capacity with
full-fare passengers have been found to dramatically improve net
operating results (on the order of 60%) with no degradation of service.

ITS training for paratransit contractors is lacking, making it difficult
for them to implement and maintain leading edge ITS technologies in a
knowledgeable way. Contracting agencies can mitigate this issue by
implementing appropriately designed and staffed technical assistance
programs.

Rideshare services are best provided by small local operators
dynamically competing for trip assignments on a day by day basis, but
the cost of initial vehicle procurement, insurance, and administration
can be a significant barrier to small operators seeking to enter the
market. A modest investment in start-up vehicles, communications
equipment, ITS training, administrative support, and quality control
staff can pay long- term dividends many times over.

The onboard components of an advanced paratransit operations system may
require greater electrical capacity than is commonly installed in
light-duty vehicles. Paratransit operators can expect an abnormally high
degree of failures when attempting to retrofit vehicle location, fare
collection, card reader, and/or communications equipment onto existing
vehicles not specifically equipped with the heavy-duty batteries,
alternators, and onboard electrical management systems required to
support them.

Fraud has proved to be an issue for some contracted paratransit
services, where agencies have been billed for ineligible trips, for
trips that were never delivered, and for trips delivered to fictitious
"phantom" riders. Automated back-office verification processes using
coded subscriber ID cards and onboard card readers can minimize the
impact of this kind of problem.

GIS-based paratransit and ridematching software systems need a detailed,
accurate base map complete with transit routes, stops, park and ride
locations, and other facilities added and maintained on a continual
basis.  This data maintenance effort should coordinated, if possible,
with other modes and agencies to avoid duplication of effort and
inconsistency in inserting new streets, correcting address ranges, and
inserting transit features. Additionally, many other TDM databases such
as the Trip Reduction Act, Employer Pass Sales programs, Ridematch
locations, and Customer Relationship Management are most usable and
maintainable when coordinated across multiple departments, modes, and
agencies. Chapter 1, Integration, addresses these issues in detail.

### 7.5.2 Automated Service Coordination Lessons Learned {#automated-service-coordination-lessons-learned .Style-Heading-3-+-Justified}

Automated Service Coordination, done correctly, while not the most
technically demanding, is perhaps the most complex transit ITS
application yet conceived, and arguably is more complex than the
intelligent vehicle and the automated highway. When properly balanced
and constrained to prevent undue impact on downstream transfers and non
connecting passengers, Automated Service Coordination provides benefits
to travelers (through improved service reliability) and also to
operating agencies (through improved vehicle utilization, employee
satisfaction, customer satisfaction, and customer loyalty). Although the
benefits are real, proper balance can be difficult to achieve and even
more difficult to assess.[^142]

Automated service coordination deployments to date have universally
neglected the need to gather information to evaluate their effectiveness
on a day to day basis. Agencies need specific information to enable them
to determine whether the system is actually improving their operations
or making them worse, and under what conditions. The Battelle Institute
study[^143] on this subject is required reading.

### 7.5.3 Multimodal Transportation Management Center Lessons Learned {#multimodal-transportation-management-center-lessons-learned .Style-Heading-3-+-Justified}

The extraordinary complexity of coordinating and maintaining multimodal
transportation information at a regional Web site that is comprehensive,
accurate, and user friendly cannot be overstated. The great majority of
the planning that should go into such a system needs to be in the areas
of data maintenance (a reliable process for receiving updates from
participating agencies), data validation (ensuring that updates contain
all the required data, in the correct format), and data synchronization
(ensuring that all the correct information is available for a given
day). Unfortunately, most project plans to date have tended to grossly
underestimate the effort required in these areas (by as high as three or
four times the original estimate), focusing instead on the itinerary
planning engine and the user interface itself.

Various agencies, of various modes, have cited institutional issues that
have slowed the development of multimodal transportation management
centers, not only across different agencies (transit versus highway, or
toll authority versus DOT), but across different modes within a given
agency (bus versus rail) as well. This is not surprising given that
agencies are not typically evaluated or rewarded based on their
cooperation with others. Based on similar cases from the conventional
business management literature, it appears reasonable to expect that the
development and publication of summary performance measures and
management incentives that track and reward overall transportation
efficiency and effectiveness at the state or Metropolitan Planning
Organization (MPO) level without distinguishing individual modes or
agencies could be a useful tool in promoting an enhanced sense of
multimodal interagency teamwork in this area.

As noted in State of the Art Update 2000, most metropolitan areas appear
to be leaning toward the creation of "virtual" regional transportation
management centers (i.e., individual agencies linked electronically)
rather than new co-located facilities. It should be noted, however, that
quality of service on an unhardened communications link may be subject
to compromise, especially in times of natural or man-made disaster when
a closely coordinated response is likely to be needed the most.

The co-located facility is believed by many practitioners to offer
better coordination during emergency situations and major incidents when
traffic needs to be diverted than is likely in a "virtual" center, but
this improved coordination may carry with it the additional risk of a
single point of failure for an entire region. The optimum balance of
cost, scale, performance, survivability, and reliability has yet to be
determined.

Most transportation professionals believe that mode and route choice
decisions are made based on differences in the perceived convenience,
cost, reliability, and performance of the various options available, yet
no effort has yet been made to facilitate travelers' ability to actually
make this comparison across modes. Every "multimodal" transportation
information system deployed to date has been built in such a way as to
prohibit co-mingling of performance information from different modes on
a single map display. Travelers are shown transit or highway
information, but never both on the same display. Implementers should
consider facilitating an informed mode choice decision through
development of performance and reliability measures that are consistent
for both roadway and transit, with concurrent display on a single
regional map.

The leap from information portal to integrated management center is a
big one. It is best made incrementally, one application at a time. A
logical first step is the integration of geocoded traffic status and
incident information into a bus Computer Aided Dispatch (CAD)
application in return for probe-derived roadway performance data.

## 7.6 References {#references-5 .Style-Heading-2-+-Justified}

Battelle Memorial Institute. "Evaluation of Utah Transit Authority's
Connection Protection System, Final Project Report," Federal Highway
Administration Report 14074, May 2004.
[www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE//14074.htm](http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE//14074.htm).

"Mobility Services for All Americans" (MSAA),
[www.its.dot.gov/msaa](http://www.its.dot.gov/msaa), and "United We
Ride," [www.unitedweride.gov](http://www.unitedweride.gov/). These two
USDOT-led initiatives focus on enhancing human service transportation
coordination and delivery, including using ITS to facilitate dynamic
rideshare and single point of service access.

# Chapter 8 Intelligent Vehicle Systems

## 8.1 Introduction and Technology Overview  {#introduction-and-technology-overview-5 .Style-Heading-2-+-Justified}

From its modest beginnings under the federal Intelligent Vehicle
Initiative (IVI), the development of Intelligent Vehicle Systems (IVS)
technologies has expanded from a federal "initiative" to a much broader
role that provides transit with core business tools. As a result of
these efforts, state-of-the-art intelligent vehicle systems now provide
transit with advance warnings of impending mechanical and electrical
failures, integrated single-point operator sign-on of various onboard
systems, management of onboard devices, adaptive vehicle control, route
guidance, rear-end collision warnings, and automatic next-stop
annunciation for passengers. Additional transit applications expected to
be deployed in the near term include automatic detection of under
inflated tires (a leading cause of premature tire failure), low
visibility vision enhancement, lane-keeping assistance, and automatic
driver impairment detection.

"Intelligence" in an onboard vehicle system implies the capacity to
acquire and apply knowledge, the ability to cope with demands created by
novel situations and new problems, and to apply what is learned from
experience as effective guides to behavior.[^144] Through the use of
electronics, intelligent onboard systems automatically acquire relevant
data from internal sensors and other systems throughout the vehicle and
the surrounding environment. These advanced onboard systems then compare
and process those data to create actionable information, coordinate
responses with other systems, monitor the correctness and effectiveness
of those responses, and modify subsequent processing and responses
accordingly. It is the cooperative and interactive aspects of these
systems that distinguish them from their "less intelligent" or "dumb"
predecessors, which were limited by simple programming and lack of
standardized interfaces.

For purposes of this report, IVS have been divided into three major
categories:

> Onboard Integration
>
> Advanced Vehicle Safety Systems
>
> Vehicle Guidance/Automation

"Onboard Integration" has been further divided into "Intelligent Onboard
Bus Integration" and "Intelligent Rail Vehicle Integration."

Examples of IVS technologies include:

> Global Positioning System (GPS)-based route guidance and navigation;
>
> Communications-Based Train Control (CBTC);
>
> Digital onboard Vehicle Area Networks (VAN) and Trainline networks;
>
> Short-range wireless communications;
>
> Mobile Data Terminals (MDT);
>
> Multiplexed electrical systems;
>
> Adaptive braking;
>
> Adaptive traction control;
>
> Adaptive cruise control;
>
> Adaptive power management;
>
> Infrared vision enhancement;
>
> "Heads Up" Displays (HUD);
>
> Wheel/tire temperature and air pressure monitoring;
>
> Precision steering and docking;
>
> Onboard Supervisory Control and Data Acquisition (SCADA);
>
> Short-range Radio Direction and Ranging (RADAR) proximity sensing;
>
> Short-range ultrasonic proximity sensing;
>
> Machine vision; and
>
> Interactive electronic defect card.

Intelligent Vehicle Systems interact cooperatively with other systems
onboard the vehicle, with wayside systems, and ultimately with onboard
systems of other vehicles to provide benefits that could not be
otherwise achieved with stand-alone equipment. For example, IVS
applications could ultimately reduce bus fuel consumption, maintenance
costs, and running time variation by:

> Determining the vehicle's expected time of arrival at an upcoming
> intersection (taking into account past history, current speed, traffic
> levels, and active stop requests);
>
> Communicating with the wayside traffic signal controller to request
> priority handling at a particular intersection;
>
> Determining in advance what signal will actually be displayed at the
> time the vehicle is expected to arrive; and
>
> Informing the operator whether it would be advisable to maintain speed
> or decelerate for an expected stop signal.

Integration with an adaptive cruise control capability would then not
only notify the operator, but also would automatically slow down the
vehicle.

IVS applications also could ultimately alert the operator of fatigue or
impairment, adverse trends in vehicle condition, and deviations from
scheduled times and headways. These systems could also assist the
operator in keeping the vehicle centered within the lane and maintaining
a safe distance from the vehicle ahead, thereby avoiding impending
collisions.

Similarly, IVS on a commuter train or rapid transit vehicle could
ultimately reduce energy costs by coordinating traction power draw with
that of other nearby trains to minimize peak load on the overhead
catenary (electrical power supply), while simultaneously determining
expected times of arrival at upcoming grade crossings, and then
communicating with automatic grade crossing controllers to allow
coordination of traffic signals to minimize disruption of local traffic
flows. Onboard components could also monitor vehicle condition and note,
for example, doors and equipment that the crew has had to "cut out" or
bypass because they require maintenance or repair.

All of the scenarios described above are possible with available IVS
technology. To date, however, U.S. transit agencies have explored only a
few of the possible applications. The following sections outline the
current state of the art in actual IVS deployments as well as emerging
IVS trends.

## 8.2 Intelligent Onboard Bus Integration  {#intelligent-onboard-bus-integration .Style-Heading-2-+-Justified}

### 8.2.1 Technology Description {#technology-description-20 .Style-Heading-3-+-Justified}

Intelligent Onboard Bus Integration provides the means by which various
stand alone equipment modules found on a transit bus can be made to
interoperate with each other. The ability of this equipment to work
together maximizes the functionality, reliability, usability,
efficiency, and effectiveness of the overall transit operation, while
minimizing total life cycle cost (LCC). Moreover, effective onboard
system integration that results in fewer and simpler user interfaces
will also be the key to realizing potential improvements in vehicle
safety by facilitating driver acceptance of a wide variety of ITS
collision avoidance technologies.[^145]

Intelligent Onboard Bus Integration comprises a family of enabling
technologies that operate at the top level of an onboard architecture,
linking major electronically controlled components through a common
communications protocol or "language" understood by all equipment on the
network. The enabling technologies include digital networks, standard
interface profiles, and computer software drivers that translate
messages between the standard language of the network and the native
language of a given electronic device.

For communications that take place below the top levels of the
architecture, almost any network protocol will do. For example, for an
Automatic Passenger Counter (APC), it may not matter what protocol is
used to send information between the passenger count sensor and the
device that first interprets the sensor's output into discrete boardings
and alightings, if that device lies between the sensor and the vehicle
network. Most modern vehicles host at least four distinct "non-standard"
or "proprietary" interface profiles at this level for communicating raw
data between the various subsystem components. These interfaces are
often built on a general purpose interconnection technology such as
Electronic Industries Alliance (EIA) RS232, RS422, or RS485, with little
or no adverse effect on system integration.

However, for the processed APC boardings and alightings to be integrated
with a vehicle location component and stored by an onboard event
recorder to provide an account of passenger activity at each specific
bus stop, a standard interface that allows messages to be clearly
understood by each involved system is critical. In addition, if the
network is to freely support components from different manufacturers, it
is also essential that this standard interface be "open," meaning that
it is thoroughly documented, unrestricted, and usable by all.

Currently, the most commonly used open network technology for
state-of-the-art intelligent onboard bus integration is one built on the
Society of Automotive Engineers (SAE) J1708 standard for serial data
communications between microcomputer systems in heavy duty-vehicle
applications.

Control for engines, transmissions and antilock brake systems (ABS)
(i.e., the vehicle, "powertrain") has shifted exclusively to the much
faster SAE J1939 network due to the safety-critical nature of the
communication (i.e., the need for ABS to react quickly once a locked
brake is detected). All major equipment vendors and bus manufacturers,
however, still support a J1708 data interface because the speed of the
J1708 interface is considered sufficient for non-powertrain related data
communications. Given that J1708 can also be used like a "gateway" that
grants access to devices that need powertrain data, and since a large
installed base of J1708-based monitoring components and diagnostic
equipment already exists in the commercial trucking industry, use and
availability of SAE J1708 devices is expected to continue for the
foreseeable future.

Likewise, multiplex suppliers who provide microprocessor-based systems
that control basic onboard electrical functions such as activating
lights and door interlocks may typically use a proprietary data network
to achieve that control, but often offer an optional SAE J1708 interface
to provide integration with other onboard systems.

State-of-the-art light rail applications, which are most often patterned
after bus rather than heavy rail transit, also typically employ the SAE
J1708 standard for digital communications between onboard subsystems,
and tend to share common communications, vehicle location, passenger
counting, and passenger information equipment with their bus
counterparts.

Less common is the Information Technology (IT) industry standard
"Ethernet," which can be used in wireless, wireline, and fiber optic
implementations using easily readable Extensible Markup Language (XML)
text files to convey messages between onboard components. Wireless
Ethernet technology is currently the emerging industry standard for
vehicle-to-wayside communications, and is commonly used for such
automated garage-based applications as upload of sign and schedule
tables and download of event recorder, vehicle health monitoring, and
passenger count data. The use of Ethernet for onboard communications may
also grow if strong IT departments are successful in driving their
agencies away from J1708 in favor of an IT-managed personal computer
(PC) onboard operating system model.

Additionally, where network communications are required to span a
particularly difficult wiring environment, for example in retrofitting
an articulated bus or light rail car, agencies can expect increased use
of the "Bluetooth" short range wireless connectivity standard.

All of these standard networks are complimented by standard interface
profiles that provide recommended data definitions and messages for use
on the network. The SAE J1587 recommended practice for electronic data
interchange is one such interface profile that many readers may be
familiar with because it is designed for use with the SAE J1708 network.
SAE J1587 defines standard message identifiers (MIDs) and parameter
identifiers (PIDs) that clearly indicate the type of data requested and
the value, unit, and context of the information being conveyed in
return. By using these defined profiles as a starting point, interface
software within a network-enabled device can easily interpret between
the standard messages on the network and whatever communications scheme
may be native to the respective device.

The great majority of recent system implementations have included some
degree of onboard system integration across a standard network. Most
common is integration between an AVL system, the powertrain, and an
automatic passenger counting (APC) system to provide an event logging
function that captures time-stamped vehicle condition, ridership, and
vehicle position information for offline analysis. Somewhat less common
at present, but becoming more commonplace in state-of-the-art
deployments, is the addition of stop annunciation, destination sign
control, digital video recording, and fare collection to provide
single-point operator sign-on for all onboard systems.

Figure 21 illustrates a possible migration path to a nearly fully
integrated onboard architecture.

[]{#__RefHeading___Toc129324163 .anchor}Figure 21 NJ TRANSIT Bus
Management Information System Onboard Architecture

> []{.mark}
>
> ![](media/image32.jpeg){width="6.495833333333334in"
> height="3.786111111111111in"}

### 8.2.2 State of the Art {#state-of-the-art-21 .Style-Heading-3-+-Justified}

Onboard system integration is not new. What is unique to
state-of-the-art onboard bus integration, however, is the degree of
cooperative interoperability and multi vendor interchangeability
provided by a well and fully standardized onboard network architecture.

State-of-the-art onboard bus integration is distinguished by such
features as:

> Multi vendor interchangeability of vehicle location systems, vehicle
> processors, fare card readers, passenger counters, voice annunciation,
> video recording, data terminal, passenger display, and destination
> sign components;
>
> Single-point operator sign-on;
>
> Single sources for providing vehicle location, odometer, vehicle
> identification (ID), current time, block, route, run, and trip
> information, the data from which are shared via the onboard network by
> all onboard systems that need them;
>
> Automatic acquisition of vehicle ID by newly installed data terminals,
> event recorders, and vehicle processors;
>
> Odometer, time and location-tagged arrival, departure, passenger
> count, fare transaction, wheelchair lift, and video event records for
> each stop;
>
> Odometer, time and location-tagged powertrain alarm, and vehicle
> health monitoring event records;
>
> Conditional control of signal priority requests; and
>
> System initialization and exception event records tagged with
> component serial number and software version ID.

Some level of operational integration is now the norm, where at least
some of the installed systems routinely share information with one
another in near real time over a standard onboard network. Integration
to provide a single point of administration for these systems (e.g.,
updating internal software, files, and tables), however, has not yet
been accomplished.

System administration often involves the transfer of files that are
simply too large to transmit efficiently across a SAE J1708 network
without disrupting the integrated operation of the onboard systems.
Currently, which may be sufficient for most agencies, the
state-of-the-art for system administration consists of individual
wireless network connections to each installed system (or occasionally
to each group of systems if purchased from the same vendor) from a
common wireless LAN (Local Area Network) access point located at the
base facility. These multiple links provide automatic updates of
operating software sign files, schedules, map data, fare tables and
voice annunciator files, and automatic download of event recorder data
and digital video images --- each over its own dedicated wireless LAN
connection to the shared garage access point.

Examples of state-of-the-art onboard bus integration deployments found
in transit include:

> Centro, Syracuse, NY
>
> Integration across vehicle location, passenger counting, data
> terminal, fare payment, and vehicle health monitoring systems[^146]
>
> Some issues regarding fare collection[^147]
>
> 185 equipped vehicles[^148]
>
> GC-RTA, Cleveland, OH
>
> Integration across vehicle location, passenger counting, data
> terminal, fare payment, voice annunciation, and vehicle health
> monitoring systems[^149]
>
> Some issues regarding voice annunciation[^150]
>
> 675 equipped vehicles[^151]
>
> LACMTA, Los Angeles, CA
>
> Integration across vehicle location, passenger counting, data
> terminal, fare collection, destination sign, video recording, voice
> annunciation, and vehicle health monitoring systems with single-point
> operator sign on[^152]
>
> 2,400 equipped vehicles[^153]

### 8.2.3 Emerging Trends {#emerging-trends-13 .Style-Heading-3-+-Justified}

The inability of the most common onboard operating networks to
efficiently support the system administration function, together with
the perceived "inelegance" of a collection of apparently redundant
onboard wireless LAN transceivers, inexpensive as they may be, has
prompted at least one major agency IT department[^154] to suggest
another approach. It involves the eventual migration of onboard systems
and software away from application-specific onboard networks and
industrial grade operating systems, like SAE J1708 and Unix or Linux, in
favor of the conventional IT standards and PC operating systems with
which they are typically more familiar such as Ethernet, XML, and
Microsoft Windows. Whether full migration to a PC-based operating model
would be actually feasible or desirable has yet to be fully
investigated, but eventual migration to at least an IT-supported high
speed Ethernet-based onboard network does appear probable.

## 8.3 Advanced Vehicle Safety Systems  {#advanced-vehicle-safety-systems .Style-Heading-2-+-Justified}

### 8.3.1 Technology Description {#technology-description-21 .Style-Heading-3-+-Justified}

Advanced Vehicle Safety Systems form the core of IVS. They include:

> Road departure warning systems;
>
> Lane departure warning systems;
>
> Rollover warning systems;
>
> Roll stability control systems;
>
> Obstacle detection systems;
>
> Collision warning systems;
>
> Collision avoidance systems;
>
> Collision notification systems;
>
> Driver alertness monitoring systems;
>
> In-vehicle vision enhancement systems; and
>
> Pre-crash restraint deployment systems.

Road departure warning systems use machine vision and other in-vehicle
sensors to detect and alert drivers of potentially unsafe lane-keeping
practices and to help keep drowsy drivers from running off the
road.[^155] Status: Under development.

Lane departure warning systems use technologies such as machine vision,
magnetic strips, and GPS coupled with precise digital maps to warn
drivers that their vehicle is unintentionally drifting out of the
lane.[^156] Status: Commercially available on automobiles.

Rollover warning systems use an onboard map database, GPS, other onboard
sensors and, in some cases, short-range communications, to detect and
notify drivers when they are traveling too fast for an approaching curve
given current roadway conditions and the vehicle's current operating
characteristics.[^157] Status: Tested in over-the-road trucks.

Roll stability control systems take corrective action, such as
automatically applying the brakes, when sensors detect that a vehicle is
in a potential rollover situation.[^158] Status: Under development.

Rear-impact warning systems attempt to prevent accidents by using radar
detection to activate warning signs on the rear of the vehicle to warn
tailgating drivers of impending danger.[^159] Status: Under development.

Obstacle detection systems use vehicle-mounted sensors that include
microwave RADAR or machine vision to detect obstructions such as other
vehicles, road debris, or animals in a vehicle's path and then alert the
driver.[^160] Status: Under development.

Lane-change warning systems are a type of collision warning system that
use microwave RADAR or machine vision to alert bus operators to the
presence of vehicles or obstructions in an adjacent lane when the driver
prepares to change lanes.[^161] Status: Commercially available in
automobiles, buses, and over-the-road trucks.

Intersection collision warning systems are a type of collision warning
system that use machine vision, GPS, and dedicated short-range
communications to detect and warn drivers of approaching traffic at
high-speed intersections.[^162] Status: Under development.

Forward collision warning systems are a type of collision warning system
that use onboard sensors such as microwave RADAR and machine vision to
help detect and avert vehicle collisions. These systems typically use
in-vehicle displays or audible alerts to warn drivers of unsafe
following distances. If a driver does not properly apply brakes in a
critical situation, some systems take control and decelerate the engine
or apply brakes automatically in an attempt to avoid a collision.[^163]
Status: Tested in automobiles.

Advanced collision notification systems use in-vehicle crash sensors,
GPS technology, and wireless communications systems to supply
public/private call centers with crash location information, severity of
the accident, and number of passengers on board (as determined from
automatic passenger count data).[^164] Such systems may also
automatically transmit video images of the crash scene if vehicles are
so equipped. Status: Commercially available in automobiles, buses, and
over-the-road trucks.

Driver alertness warning systems use steering sensors to detect operator
behavior indicative of fatigue or impairment, and then alert the
operator and supervisory personnel of an apparent impaired condition to
help prevent an unintended lane or roadway departure.[^165] Status:
Tested in over-the-road trucks.

In-vehicle vision enhancement systems use "heads up" see-through
displays positioned directly in front of the driver's line of sight,
along with forward-looking infrared technologies, to improve visibility
for driving conditions involving reduced sight distance due to night
driving, inadequate lighting, fog, drifting snow, or other inclement
weather conditions.[^166] Status: Commercially available in automobiles
and over-the-road trucks.

Pre-crash restraint deployment systems[^167] utilize the output of
collision-warning devices to initiate just-in-time airbag deployment and
tensioning of driver restraints to protect the vehicle operator and
passengers in the event of a serious collision. Status: Tested in
automobiles.

Advanced Vehicle Safety Systems for public transit are not yet widely
deployed in the United States. Only one of the 26 agencies responding to
the 2005 State of the Art survey reported that any of these technologies
had reached operational status at their agency.

### 8.3.2 State of the Art {#state-of-the-art-22 .Style-Heading-3-+-Justified}

While an extensive variety of vision enhancement, collision detection,
and lane keeping devices are routinely being installed in many new
over-the-road trucks, this technology has not yet been deployed in
public transit in the U.S. With the notable exception of a variety of
simple but effective front, side, and rear-obstacle detection systems,
the current state of the art in advanced vehicle safety systems for U.S.
public transit has only reached the demonstration stage. No intersection
collision warning, rollover warning, roll stability control, lane
departure warning, collision notification, vision enhancement, or
pre-crash restraint deployment systems are reported to have reached
actual fleet deployment in any public transit applications in the U.S.

The current state of the art in Advanced Vehicle Safety Systems
deployments for public transit is typified by the Utah Transit
Authority, which has deployed a factory-installed side collision warning
system on about half of its 30 recently purchased small buses. The
agency believes that one of the more cost-effective uses of such a
system may be for training new bus operators rather than full fleet
deployment.

### 8.3.3 Emerging Trends {#emerging-trends-14 .Style-Heading-3-+-Justified}

Driver alertness warnings, collision notification systems, and
in-vehicle vision enhancement systems are all commercially available for
over-the-road trucks, and appear to be sufficiently proven to allow
immediate implementation in public transit. In fact, vision enhancement
systems have been available as factory-installed options in private
automobiles since 2004. All that remains is for prospective commuter
operators to specify them in upcoming procurements.

## 8.4 Vehicle Guidance/Automation  {#vehicle-guidanceautomation .Style-Heading-2-+-Justified}

### 8.4.1 Technology Description {#technology-description-22 .Style-Heading-3-+-Justified}

Vehicle Guidance/Automation systems are intended to help transit
operators link multiple buses or light rail cars into close-coupled
convoys (i.e. trains) and assist drivers with routine tasks to reduce
driver workload.[^168]

Vehicle Guidance/Automation technologies include:

> Navigation and route guidance systems;
>
> Precision docking systems;
>
> Adaptive cruise control systems;
>
> Coupling/decoupling systems; and
>
> Lane keeping assistance systems.

In-vehicle navigation and route guidance systems use GPS technology to
reduce driver error, increase safety, and save time by improving driver
decision making in unfamiliar areas.[^169] Status: Commercially
available in automobiles, buses, passenger ferries, and over-the-road
trucks.

Precision docking systems use machine vision, microwave RADAR,
communications-based train control, or magnetic tags or strips to
automate precise positioning (both longitudinal and lateral positioning)
of vehicles at loading/unloading areas.[^170] Status: Commercially
available in buses, people movers, and heavy rail (rapid transit). Under
development for passenger ferries.

Adaptive cruise control systems use microwave RADAR or laser ranging and
electronic throttle and braking actuators to maintain safe following
distance between platooned vehicles at any speed. Status: Commercially
available in automobiles and over-the-road trucks.

Coupling/decoupling systems extend the concept of adaptive cruise
control to support close-coupled vehicle operations, where vehicles
follow one another at extremely close distances, usually in an exclusive
lane. These systems use machine vision, microwave RADAR, short-range
wireless communications, and electronic actuators to provide precise
automated vehicle control in high speed Bus Rapid Transit operations.
Status: Under development.

Lane keeping assistance systems are the logical extension of a lane
departure warning system, using electronic actuators to make minor
steering corrections if the vehicle detects an imminent lane departure
without the driver using a turn signal.[^171] As currently demonstrated,
such systems are designed to apply only limited torque (approximately
two foot-pounds as measured at the steering wheel) so that they can be
easily overridden by the vehicle operator.[^172] Variations of the lane
keeping assistance concept that mechanically track the curb or a rail
imbedded in the roadway also exist. Status: Demonstrated in buses and
over-the-road trucks. Under development for passenger ferries.

Vehicle Guidance/Automation technologies are not yet widely deployed in
the United States. Only one of the 26 agencies responding to the 2005
State of the Art survey reported that any of these technologies had
reached operational status at their agency. However, mechanical lane
keeping systems have been successfully deployed for both short distance
(1,000 ft) traffic signal queue bypass lanes and medium distance (7
miles) bus rapid transit lanes in England, other parts of Europe, and
Australia.

### 8.4.2 State of the Art {#state-of-the-art-23 .Style-Heading-3-+-Justified}

Navigation and route guidance systems are relatively common in recent
state-of-the-art vehicle procurements, but the only public transit
vehicle guidance/automation application reported to have reached actual
deployment status in the United States is a precision docking
application in Las Vegas, Nevada. Although commercial applications do
exist in Europe, Asia, and Australia, the current state of the art in
U.S. vehicle guidance/automation is limited to precision docking. No
adaptive cruise control, coupling/decoupling, or lane keeping assistance
systems are reported to have been actually deployed on transit vehicles
in the United States.

Surprisingly, the current state of the art in cost-effective vehicle
guidance/automation applications does not even include an advanced
technology component. Though not sufficient for all bus rapid transit
applications, these mechanical lane keeping systems utilize horizontal
rubber guide wheels linked to the steering mechanism to maintain precise
positioning to within one inch at highway speed. They cost about \$2,500
per bus and \$2M per new lane mile to install. Lane-keeping systems
allow buses to join and leave the assisted roadway at highway speeds
and, because they can be implemented in short segments at targeted
intersections at relatively little expense, are especially well suited
to the task of cost-effectively allowing buses to bypass automobile
queues at speed using narrow guideways on the shoulder or median at
critical arterial intersections.[^173]

Examples of state-of-the-art deployment of Vehicle Guidance/Automation
deploy-ments found in transit include:

> Regional Transportation Commission of Southern Nevada
>
> Automated self-docking of ten 60-foot Bus Rapid Transit vehicles to
> level boarding platforms
>
> Machine vision technology using roof-mounted cameras to detect white
> painted lines on the roadway surface
>
> Reliable positioning with 3" tolerance between vehicle and boarding
> platform
>
> Ten equipped buses
>
> 15 stops
>
> Adelaide Metro (Australia)
>
> Mechanical lane keeping assistance system
>
> One inch position tolerance
>
> Seven miles of dedicated bus transit guideway operated on 20-second
> headways at 60 MPH
>
> 30,000 passengers per day

### 8.4.3 Emerging Trends {#emerging-trends-15 .Style-Heading-3-+-Justified}

Recent demonstrations indicate that electronic lane keeping assistance
systems can be used to allow a 102-inch wide bus to safely operate in a
114-inch-wide lane or shoulder in good conditions,[^174] but operation
in snow or icy conditions has not yet been investigated in sufficient
depth to allow deployment in central or northern regions of the
country.[^175]

## 8.5 Intelligent Rail Vehicle Integration {#intelligent-rail-vehicle-integration .Style-Heading-2-+-Justified}

### 8.5.1 Technology Description {#technology-description-23 .Style-Heading-3-+-Justified}

Like Intelligent Onboard Bus Integration, Intelligent Rail Vehicle
Integration provides the means by which the various discrete subsystems
found on a railcar can be made to interoperate to maximize the
functionality, reliability, usability, efficiency, and effectiveness of
the transit system, while minimizing total life cycle cost. The one
critical element that distinguishes rail integration from bus
integration is that rail integration not only links the discrete
subsystems on a given vehicle, but also the many vehicles (railcars and
locomotives) of a given train as well.

Because of the need to periodically couple and decouple trains of
individual cars and locomotives of different generations, rail
integration is somewhat more complicated than bus integration. The key
to rail system integration is the "trainline." A conventional trainline
is a multi conductor cable that runs the entire length of the train,
which in some cases can be a third of a mile or more. Long before
digital network technology was developed, rail operators in the U.S.
decided to implement a 27-conductor trainline --- 27 discrete wires of
various sizes for electrical power, door control, propulsion and braking
control, and public address --- with a standardized 27-pin jumper to
propagate the trainline between each car and locomotive.

To achieve intelligent rail vehicle integration, the conventional
27-conductor trainline and 27-pin jumper are supplemented by a
high-speed digital network. Interface components within the cars and
locomotives can be configured such that an equipped car can
automatically communicate with adjacent cars via the network, the 27-pin
jumper, or both, thereby allowing for mixed consists of new and old cars
to interoperate together, and providing a migration path for eventual
discontinuation of the conventional discrete wired trainline.

The potential cost savings to be gained through use of this advanced
trainline network are significant. Using the network, locomotive
engineers operating from a cab car at the far end of the train can
receive the complete range of equipment status and diagnostic
information available in the locomotive cab. Train consists, which
previously required individual cars to be oriented in the same direction
(i.e., "A" end to "B" end) for the crew to open doors only on the
platform side of the train, for example, can now be coupled
indiscriminately in any orientation because the network on each car can
adapt to whatever orientation it determines itself to be in.

Because of the greater cable distances involved, both within an 87-foot
long railcar and along a 1,200-foot-long commuter train, rail networks
tend to be built on different network technologies from their bus
counterparts. Currently, the most commonly used network technology for
state-of-the-art intelligent rail vehicle integration is that built on
the Institute of Electrical and Electronics Engineers (IEEE) standard
1473 for communications protocols aboard trains. IEEE 1473 specifies a
family of three complementary network technologies for communications
along the length of the train and within the car. Two of these require
their own independent network cabling, while the third is capable of
operating over the same cables that provide the high-voltage electrical
power to the train.

All of the recent major railcar procurements in the U.S. have included
some degree of rail system integration across a standard network. Most
common is integration between the locomotive and the remote operating
console in a cab car (to provide the full range of locomotive alarms and
diagnostics in either location), between the door control system, the
throttle, and the antilock braking system (to prevent inadvertent train
movement while boarding or discharging passengers), and between
passenger information signs throughout the train.

### 8.5.2 State of the Art {#state-of-the-art-24 .Style-Heading-3-+-Justified}

Led by the Association of American Railroads (AAR), the U.S. rail
industry has long enjoyed a level of multi vendor interchangeability of
radio systems, event recorders, mechanical components, and other such
items that is virtually nonexistent with buses. What is unique to
state-of-the-art rail vehicle integration, however, is that this
advanced level of multi vendor interchangeability has now been extended
to the car-borne control and information systems as well, allowing the
various onboard systems to deliver a much higher level of cooperation
and interoperability than ever before.

State-of-the-art rail vehicle integration is distinguished by such
features as:

> Multi vendor interchangeability of vehicle location systems, vehicle
> processors, passenger counters, voice annunciation, video recording,
> data terminal, passenger display, and destination sign components;
>
> Automatic consist identification and car orientation determination;
>
> Support for mixed-mode trainline operation (digital network versus
> 27-pin);
>
> Single-point operator sign-on;
>
> Intelligent load shedding;
>
> Full range of locomotive status and diagnostics information available
> at both locomotive and cab car;
>
> Single point of maintenance data access for all systems on a given
> car;
>
> Single point of maintenance data access for all cars throughout the
> train;
>
> Single point of file update and administration for passenger
> information, destination signs, and voice annunciators throughout the
> train;
>
> Passenger load distribution information available to both engineer and
> crew;
>
> Single sources for providing vehicle location, odometer, vehicle
> identification (ID), current time, route, and trip information shared
> by all onboard systems on the network;
>
> Passenger information displays synchronized throughout the train;
>
> Stop announcements that adapt to current location and operating
> condition, announcing destination and intermediate stops while
> boarding passengers, and providing "next stop" information between
> stations;
>
> Variable door control timing that keeps automatic vestibule doors open
> longer when stopped and boarding passengers;
>
> Automatic logging of cut out or bypassed components and features;
>
> Odometer, time and location-tagged arrival, departure, passenger
> count, and video event records for each stop;
>
> Odometer, time and location-tagged propulsion and braking alarm, and
> vehicle health monitoring event records; and
>
> System initialization and exception event records tagged with
> component serial number and software version ID.

Examples of state-of-the-art Intelligent Rail Vehicle Integration
deployments found in transit include:

> New Jersey Transit, Newark, NJ
>
> IEEE 1473 trainline network
>
> Fully networked door control
>
> 300 railcars equipped
>
> Mixed mode trainline operation
>
> MTA New York City Transit, New York City, NY
>
> IEEE 1473 trainline network on all new subway cars

### 8.5.3 Emerging Trends {#emerging-trends-16 .Style-Heading-3-+-Justified}

The IEEE Rail Transit Vehicle Interface Standards Committee (RTVISC) is
working to define the data and messages required to standardize the
administration of sign and voice annunciator systems. This work is
nearly complete. With manufacturers' costs for nonrecurring engineering
borne by early implementers, and network technology now routinely built
into new railcars and locomotives, prices for advanced rail vehicle
integration have fallen to the point where even the smallest rail
operators can take advantage of the new technology.

## 8.6 Challenges and Lessons Learned  {#challenges-and-lessons-learned-12 .Style-Heading-2-+-Justified}

### 8.6.1 Use of Standards {#use-of-standards-1 .Style-Heading-3-+-Justified}

There are two subtle issues that apply even to "standardized" message
profiles like SAE J1587 that agencies with state-of-the-art applications
have learned through experience to avoid. They include "local use codes"
and use of the "data link escape." In the case of local use codes, most
standards provide for the use of locally defined codes for cases where
the standard codes are deemed inadequate or inappropriate. Standards
also provide a "data link escape" for nonstandard file transfer. Use of
locally defined codes and the data link escape in place of standard
codes is one method that some vendors have employed to allow them to be
technically in compliance with the standard, while still continuing the
deployment of devices with proprietary interfaces that can only
interoperate with other devices obtained from the same vendor.

The practice by some vendors to deploy devices with proprietary
interfaces is made possible because the process to request an
enhancement to a standard is relatively straightforward and easy to
achieve. Commonly used interface standards are maintained by
organizations responsible for processing requests for updates and
revisions of the standards, and vendors can typically get a revision
balloted and approved in 6-9 months. As a result, agencies have learned
to build careful controls on the use of locally defined codes and the
data link escape into their procurement specifications for onboard
systems and components to avoid unintentionally proprietary interfaces.

### 8.6.2 Avoiding Sub-optimized Implementations {#avoiding-sub-optimized-implementations .Style-Heading-3-+-Justified}

Onboard system integration promises significant benefits to transit and
the riding public at relatively little cost. However, when supporting
infrastructures such as onboard networks, vehicle processors, wireless
communications, and corporate databases are implemented only to support
the limited functionality specified by an individual business unit to
fill an individual business need, these technologies begin to appear far
less cost-effective than they could be. For example, state-of-the-art
agencies have found that while an AVL or video recording system might
cost \$10,000 per vehicle, the addition of APC, equipment health
monitoring, event recording, electronic defect reporting, voice
annunciation, and single-point operator sign-on may only cost a few
thousand dollars more. Moreover, if considered in the design stage,
these additional features can easily make use of the same wireless
communications and database infrastructures that are also required for
the initial application.

### 8.6.3 Vehicle Networks {#vehicle-networks .Style-Heading-3-+-Justified}

Agencies that have installed vehicle networks onboard buses and/or
trains have found them easy to design and implement. They have also
discovered that installation is best accomplished during vehicle
assembly, rather than as a retrofit, and that use of standardized cables
and connectors can greatly simplify subsequent component installation.

Although the networks work well, agencies find that the resultant
integration of systems on the networks do not always operate as
intended. One pitfall common to many of the early system integration
efforts across a vehicle network involved vendors trying to implement
component applications without adequate testing of the various failure
modes unique to network communications. This was especially the case
with trains, where network messages must be propagated across multiple
individual vehicles. This lack of adequate testing often occurs when
agencies procure their vehicles with a technical specification rather
than a performance specification, thereby forcing them to assume much,
if not all, of the risk if the technical specification should prove
inadequate. Inadequate testing also occurs when only a few months are
allocated for it.

In essence, state-of-the-art agencies have learned to shy away from
specifying technical details and "approving" vendor designs. Instead,
they have sought out the training needed to move beyond technical and
even functional specifications (i.e., how the system operates or what
the system does) in favor of performance and behavioral specifications
(i.e., defining what the system needs to accomplish and how the system
is to function under various conditions). Agencies have learned to
specify an integrated concept of operations where "the system" is not
any one component, but represents the totality of the various components
and subsystems involved in the overall vehicle integration effort.

Agencies with state-of-the-art deployments have also learned to specify
the minimum modularity required of the vehicle architecture, and make
certain that they retain unrestricted rights to every interface into and
out of every component on the vehicle to assure multi vendor
interchangeability and ease of system administration and upgrade ability
throughout the network.

Finally, agencies have learned to conduct prototype testing for
prolonged periods of six months or more, and to base final acceptance on
the original performance specification. Testing is required for each and
every specified requirement, rather than discrete subsystem tests based
on convenient pieces of the vendor's subsequent functional or design
specifications. Agencies have also learned to take delivery of at least
one complete bench test vehicle emulator for their own use in
troubleshooting equipment failures after deployment.

### 8.6.4 System Administration {#system-administration .Style-Heading-3-+-Justified}

Operational integration is only part of state-of-the-art system
integration. It also includes wireless system administration, providing
the ability to remotely update destination sign, schedule and
annunciator files, fare tables, and software without ever visiting the
vehicle. Wireless administration promises real reductions in operating
and maintenance costs for intelligent vehicle systems. Savings can
amount to \$15 per application, per vehicle, per quarter, or \$3,600 per
vehicle over a 15-year life on a vehicle equipped with fare collection,
stop annunciation, destination signs, and AVL. However, vehicle-wide
wireless administration is not yet a reality. Some agencies have
implemented wireless administration for some onboard systems, but none
have yet completely eliminated the need to physically visit the vehicle
for routine system administration and troubleshooting.

### 8.6.5 Intelligent System Integration {#intelligent-system-integration .Style-Heading-3-+-Justified}

Transit agencies and vendors alike are breaking new ground as they
strive to compress data entry and display for multiple applications into
fewer and fewer discrete user interface devices.

For noncritical system integration, where the vehicle operators can take
the time to look down and choose between the various inputs available to
them, a user interface with a hierarchical "chapter and page"
organization appears to work well enough. These hierarchical user
interfaces are often supplemented with a global system status page
providing an integrated presentation of the health and status of the
various vehicle systems.

For safety-critical integration, there is a need to provide real-time
input to the vehicle operator that is invariably clear, correct, and
complete. However, additional research and experimentation will be
required before an optimal real-time user interface can emerge. The same
holds true with regard to integration between vision enhancement, lane
keeping, and collision avoidance.

### 8.6.6 Advanced Vehicle Safety Systems {#advanced-vehicle-safety-systems-1 .Style-Heading-3-+-Justified}

While some advanced vehicle safety systems can be deployed with little
user interaction (e.g., pre-crash restraint deployment), most AVSS
applications will require extensive work toward user acceptance. For
example, vehicle operators must be able to understand and trust the
output of these systems.

Early researchers have concluded that, especially with respect to
collision warning and avoidance systems, the integration of various
separate warning systems into a user interface that presents a clear and
unambiguous message to a (possibly stressed) vehicle operator will be a
critical element of gaining this acceptance.[^176] Additionally,
although outside the purview of this state-of-the-art discussion, it
should be noted that as with any safety-related item, the real issues
may be institutional rather than technical. Liability issues can be
expected to play a determining role in AVSS deployment.

## 8.7 References {#references-6 .Style-Heading-2-+-Justified}

Adelaide O-Bahn, Adelaide Metro, Government of South Australia,
Adelaide, AU, 2005,
[www.adelaidemetro.com.au/guides/obahn.html](http://www.adelaidemetro.com.au/guides/obahn.html).

Bus Rapid Transit Lane Assist Technology Systems, Metro Transit and
University of Minnesota, Minneapolis, MN, 2003.
[www.its.umn.edu/research/applications/brt/laneassist/LAfinal1.pdf](http://www.its.umn.edu/research/applications/brt/laneassist/LAfinal1.pdf)

Multimodal Vehicle Assist and Automation: VAA Systems for Transit
Operations, Hardy and Proper, Mitretec Systems, Washington, DC, 2005.

[Consumer Acceptance of Automotive Crash Avoidance Devices]{.underline},
Charles River Associates, Boston, MA, 1998.

*Intelligent Transportation Systems Technology Overview*, U.S.
Department of Transportation, ITS Joint Program Office, Washington, DC,
2005. http://itsdeployment2.ed.ornl.gov/technology_overview.

# Appendix A Press Release Dated May 23, 2005 {#appendix-a-press-release-dated-may-23-2005 .Closing}

**FTA ITS REPORT SEEKS INFORMATION ON**

**STATE-OF-THE-ART OF TRANSIT ITS FROM**

**TRANSIT AGENCIES AND VENDORS**

May 23, 2005 --- The Federal Transit Administration (FTA) is preparing
its seventh in a series of Intelligent Transportation Systems (ITS)
State of the Art (SOA) reports for 2005. Information contained in these
reports highlights the very best transit ITS deployments (also known as
Advanced Public Transportation Systems, or "APTS") and serves as a
useful communication tool to inform the industry of this increasingly
complex subject.

In addition to highlighting successful ITS applications, FTA's SOA
Report will provide a description and overview of each major ITS
technology, highlight the lessons learned by agencies with successful
implementations, and present the issues and hurdles surrounding ITS
deployments. The SOA 2005 report will also include a stronger focus on
many of the important but often overlooked support systems and business
processes needed to successfully implement ITS technologies. All of the
major public surface transportation modes will be addressed, including
bus, rail, ferry, and intermodal service operations.

The FTA Intelligent Transportation Systems Office has contracted with
the Palisades Consulting Group, Inc. of Tenafly, New Jersey, to prepare
its next SOA report. As part of its search for SOA information,
Palisades is asking transit agencies and vendors with successful ITS
implementations to complete a simple, online form:
[www.palisadesgroup.com/StateOfTheArtQuestionnaire.htm](http://www.palisadesgroup.com/StateOfTheArtQuestionnaire.htm).
The cutoff time and date for submitting the surveys is **5 pm, EDT on
June 15, 2005.** A Palisades representative will follow up with
additional questions if needed.

Topics where information is requested include:

> **ITS Integration**, including transit ITS standards and architecture,
> geographic information systems (GIS), and enterprise data;
>
> **Fleet Management**, including communication systems (i.e., radio,
> AVL, etc.), service planning support systems, transit signal priority,
> and transportation operations systems;
>
> **Electronic Fare Payment**, including fare system, fare payment
> products, and clearinghouse/regional service centers;
>
> **Traveler Information**, including pre-trip information systems,
> in-terminal/wayside systems, in-vehicle systems, multimodal systems,
> and transit trip information infrastructure;
>
> **Transit Safety and Security**, including vehicle, facility, and
> station security, incident response, and incident planning and
> management systems;
>
> **Transportation Demand Management**, including dynamic ridesharing,
> automated service coordination, and multimodal transportation
> management centers; and
>
> **Intelligent Vehicle Systems**, including onboard bus integrations,
> Intelligent Vehicle Initiative, and intelligent rail vehicle.

For additional information about the project, contact Eva Lerner-Lam,
Palisades Team Project Director, at 201-567-0088, ext. 11 or
<elernerlam@palisadesgroup.com>.

\###

# Appendix B State of the Art Update Survey {#appendix-b-state-of-the-art-update-survey .Closing}

![](media/image33.png){width="1.0729166666666667in"
height="1.0729166666666667in"}

![](media/image34.jpeg){width="0.90625in" height="0.28125in"}

**Transit ITS (APTS)**

**State of the Art Update Survey**

Are you on the cutting edge of Advanced Public Transportation Systems
(APTS) technology? Is some aspect of your system smarter, faster,
cheaper, more capable or easier to use than anyone else's? Is it more
reliable? More maintainable? Is there something you've done
institutionally that allows you to reap greater benefits from the system
than most others might?

Please take a few minutes to help your peers throughout the transit
industry by identifying state-of-the-art APTS applications for inclusion
in the next edition of FTA's Advanced Public Transportation Systems
(APTS) State of the Art report.

Top of Form

Organization Name: ![](media/image35.wmf){width="2.7083333333333335in"
height="0.25in"}

Website Address: ![](media/image36.wmf){width="2.734027777777778in"
height="0.25763888888888886in"}

E-mail Address: ![](media/image36.wmf){width="2.734027777777778in"
height="0.25763888888888886in"}

In which areas have you deployed what you believe to be truly innovative
APTS applications?  (please check all that apply):

**System/Data Integration\
**![](media/image37.wmf){width="0.28125in" height="0.25in"}    Wireless
Communications\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Transit ITS
Architecture (open systems integration)\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Transit ITS
Standards\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Geographic
Information Systems (GIS)\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Enterprise
Data Management

What makes these systems different from what's been done before?

![](media/image38.wmf){width="3.1979166666666665in"
height="0.6979166666666666in"}

**Fleet Management**\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Service
Planning Support Systems (e.g., APC)\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Transit
Signal Priority\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Maintenance
Management Systems\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Computer
Aided Dispatch (bus, rail, ferry, paratransit, etc.)

What makes these systems different from what's been done before?

![](media/image38.wmf){width="3.1979166666666665in"
height="0.6979166666666666in"}

**Traveler Information**\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Transit
Information Systems (pre-trip, enroute, onboard, at stop, personalized,
etc.)\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Multimodal
Travel Information\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Transit
Information Infrastructure (architecture, data sets, trip planning
engines, etc.)

What makes these systems different from what's been done before?

![](media/image38.wmf){width="3.1979166666666665in"
height="0.6979166666666666in"}

**Transit Safety and Security**\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Onboard
Security\
![](media/image37.wmf){width="0.28125in" height="0.25in"}   
Station/Facility Security\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Incident
Response\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Disaster
and Incident Management Planning Support Systems

What makes these systems different from what's been done before?

![](media/image38.wmf){width="3.1979166666666665in"
height="0.6979166666666666in"}

**Transportation Demand Management**\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Dynamic
Ridesharing\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Automated
Service Coordination\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Multimodal
Transportation Management\
(parking management, modal demand management, etc.)

What makes these systems different from what's been done before?

![](media/image38.wmf){width="3.1979166666666665in"
height="0.6979166666666666in"}

**Intelligent Vehicle Systems**\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Intelligent
Onboard Integration (bus, rail, etc.)\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Advanced
Vehicle Safety Systems\
![](media/image37.wmf){width="0.28125in" height="0.25in"}    Vehicle
Guidance/Automation

What makes these systems different from what's been done before?

![](media/image38.wmf){width="3.1979166666666665in"
height="0.6979166666666666in"}

**Other (please specify)**

> ![](media/image39.wmf){width="3.2291666666666665in" height="0.25in"}
>
> ![](media/image39.wmf){width="3.2291666666666665in" height="0.25in"}
>
> ![](media/image39.wmf){width="3.2291666666666665in" height="0.25in"}

**Were especially innovative management and/or procurement methods
critical to successful implementation of any of the applications noted
above?**

![](media/image40.wmf){width="0.28125in" height="0.25in"}Yes

![](media/image40.wmf){width="0.28125in" height="0.25in"}No

If yes, please explain

![](media/image41.wmf){width="3.5625in" height="0.96875in"}

**What are some of the most interesting APTS applications you have seen?
Why? At which agencies?**

![](media/image42.wmf){width="4.03125in" height="1.1354166666666667in"}

**Do you collect Return on Investment (ROI) data on any of your advanced
systems?\
**![](media/image40.wmf){width="0.28125in" height="0.25in"}    Yes    

![](media/image43.jpeg){width="5.625in"
height="2.7680555555555557in"}![](media/image40.wmf){width="0.28125in"
height="0.25in"}    No

![](media/image44.wmf){width="0.46875in"
height="0.3125in"}![](media/image45.wmf){width="0.5104166666666666in"
height="0.3125in"}

Bottom of Form

Thank you for your input and your time.

Questions about the State of the Art update report? Write us at
<Survey@palisadesgroup.com>.

# Appendix C Information Technology (IT) Local Area/Wide Area Networking Strategies {#appendix-c-information-technology-it-local-areawide-area-networking-strategies .Closing}

+----------------------+-------------------------------+---------------+
| > **IT Network       |                               |               |
| > Architecture       |                               |               |
| > Table**            |                               |               |
+======================+===============================+===============+
| > **Transitional**   | > **State-of-the-Art**        | >             |
|                      |                               |  **Emerging** |
+----------------------+-------------------------------+---------------+
| > **OSI Layer 1 -    |                               |               |
| > Physical**         |                               |               |
+----------------------+-------------------------------+---------------+
| > Coaxial cabling,   | > Category 5e UTP (supersedes | > Category 6  |
| > Category 3         | > Category 5 UTP),            | > UTP,        |
| > unshielded twisted | > 50/125-micron multimode     | > wireless.   |
| > pair (UTP),        | > fiber, 6/125-micron         | >             |
| > shielded twisted   | > single-mode fiber.          | > Logical     |
| > pair (STP), and    | >                             | > meshed star |
| > 62.5/125-micron    | > Logical star topology,      | > topology    |
| > multimode fiber.   | > SONET, ISDN/PRI, xDSL,      |               |
|                      | > cable modem protocols       |               |
+----------------------+-------------------------------+---------------+
| > **OSI Layer 2 --   |                               |               |
| > Data Link**        |                               |               |
+----------------------+-------------------------------+---------------+
| > Single-segment     | > Open-standards-based,       | > Packet- and |
| > LANs, separate     | > multiservice networks;      | > cell-based  |
| > dedicated networks | > 100/1000 Ethernet; 802.11   | > wireless,   |
| > for different      | > LAN, 802.16 MAN Wireless    | > dynamic     |
| > services (e.g.,    | > Ethernet; Frame Relay; ATM. | > data-link   |
| > voice and data),   |                               | > level       |
| > separate dedicated |                               | > switching,  |
| > networks for       |                               | > and         |
| > various user       |                               | > pr          |
| > groups,            |                               | ioritization, |
| > proprietary        |                               | > 10G/40G     |
| > protocols (        |                               | > Ethernet.   |
| > DECnet), FDDI,     |                               |               |
| > X.25, time-domain  |                               |               |
| > (channelized)      |                               |               |
| > protocols (e.g.,   |                               |               |
| > SDLC, HDLC).       |                               |               |
+----------------------+-------------------------------+---------------+
| > **OSI Layer 3 --   |                               |               |
| > Network**          |                               |               |
+----------------------+-------------------------------+---------------+
| > Separate dedicated | > Converged networks with     | > Dynamic,    |
| > networks for       | > prioritization for all      | >             |
| > different services | > services; switched,         | network-level |
| > (e.g., voice and   | > multisegment design; IP;    | > switching   |
| > data), flat        | > RIP; BGP; OSPF; IP          | > and         |
| > designs with       | > switching; and DHCP.        | > pr          |
| > unmanaged bridges, |                               | ioritization. |
| > hubs, proprietary  |                               | >             |
| > protocols (e.g.,   |                               | > VoIP, H.323 |
| > IPX, and DECnet).  |                               |               |
+----------------------+-------------------------------+---------------+
| > **OSI Layer 4 --   |                               |               |
| > Transport**        |                               |               |
+----------------------+-------------------------------+---------------+
| > Fixed IP           | > Converged networks with     | > IPv6 and    |
| > addressing and     | > prioritization for all      | > dynamic     |
| > proprietary        | > services, TCP, and UDP.     | > tr          |
| > protocols, e.g.,   |                               | ansport-level |
| > SPX                |                               | > switching   |
|                      |                               | > and         |
|                      |                               | > pr          |
|                      |                               | ioritization. |
+----------------------+-------------------------------+---------------+
| > **OSI Layer 5 --   |                               |               |
| > Session**          |                               |               |
+----------------------+-------------------------------+---------------+
|                      | > DNS                         | > Dynamic,    |
|                      |                               | >             |
|                      |                               | session-level |
|                      |                               | > switching   |
|                      |                               | > and         |
|                      |                               | > pr          |
|                      |                               | ioritization. |
+----------------------+-------------------------------+---------------+
| > **OSI Layers 6 and |                               |               |
| > 7 --Presentation   |                               |               |
| > and Application**  |                               |               |
+----------------------+-------------------------------+---------------+
|                      | > SNMP; RMON; SMTP.           | > Dynamic,    |
|                      |                               | >             |
|                      |                               | content-level |
|                      |                               | > switching   |
|                      |                               | > and         |
|                      |                               | > pr          |
|                      |                               | ioritization. |
+----------------------+-------------------------------+---------------+

# Appendix D Fleet Management Example of a Performance-Based Specification Template {#appendix-d-fleet-management-example-of-a-performance-based-specification-template .Closing}

Below is a sample specification template that illustrates key features
of a performance-based approach to procurement of a fleet management
system.

*Note: As might be expected, because this recommended outline is for
"performance-based" specifications rather than the traditional "design"
specification, it deviates significantly from the sample 6-section
design specification format provided in the FTA Best Practices
Procurement Manual.*

**Project objective**. Example: To construct and implement a new transit
management center and statewide radio infrastructure, and to deploy an
expandable, maintainable, automated system for planning, managing, and
controlling bus, paratransit, ferry, and passenger information
operations and maintenance throughout the *(agency)* service area on
\_\_\_ buses, \_\_\_ paratransit vehicles, \_\_\_ passenger ferries, and
\_\_\_ nonrevenue vehicles operated out of \_\_\_ vehicle base
facilities...

**Project scope**. Example: The contractor shall provide all tools,
equipment, materials, software, and services required to achieve the
project objective, per these specifications, with the exception of ...,
which will be provided by *(agency)* or others, together with five years
of comprehensive unlimited warranty support for installed hardware and
five years of software maintenance support.

Critical mission requirements (basic acceptance criteria) with separate
specifications for as many distinct operational environments as may
exist. Example:

> The system shall allow authorized personnel to... *(do whatever, in
> whatever situations, with whatever levels of effort, accuracy, and
> performance that the agency requires)*;
>
> The system shall provide to passengers with telephone access at any
> and all bus stops following information: "next bus to \_\_\_\_\_\_
> will arrive in \_\_\_ minutes" accurate to within: a) 5 minutes in
> greater than 99 percent of all cases, and b) 3 minutes in greater than
> 95 percent of all cases;
>
> The system shall provide a means for vehicle operators to initiate
> communications with the control center with a single action;
>
> The system shall allow authorized users to view and report response
> times and lost call rates for all communications;
>
> The system shall allow control center personnel to respond to priority
> requests to talk within 15 seconds of the operator's initiation of the
> request in greater than 99.98 percent of all cases;
>
> The system shall automatically report failure of any system component
> within 12 hours of failure occurrence;
>
> The system shall continue to provide required functional performance
> during periods of power failure, single equipment failure...;
>
> ... and many more, as required.

Additional desired features/characteristics with anticipated annual
value to the agency for each. Note: Stating the anticipated value of
each additional desired feature up front helps prevent casual items from
driving up project cost, allows vendors to develop more responsive
proposals, and sets the stage for collaborative value engineering prior
to issuance of the final amended RFP to short-listed firms.

Concept of operations (i.e., use-case scenarios, expected sequence of
events, and degree of manual intervention required to carry out a given
operation.)\
Example: Load a new schedule, locate a vehicle, degree of automation,
etc.

Nonfunctional requirements. Example: Scalability, overall system
reliability, multi-vendor component availability, life cycle support for
hardware and software maintenance, mean time between component failures,
mean time to repair, etc.

Design Constraints. Example: preferred operating system, preferred
database management system, preferred communications provider, required
third-party tools, user interface specifications, required modularity,
architectural interfaces, interface standards, profiles, etc., with the
anticipated annual value to be gained through each.

Training and Documentation requirements. Note: The documentation should
be tested for accuracy and completeness just as rigorously as the system
itself.

Acceptance test scenarios for system and associated documentation,
identifying any special cases and boundary conditions that may be
important to the agency. Example: Provide scenarios that the agency
staff may consider to be difficult for a vendor's system to handle
properly, either in general or in their specific operating environment.
System performance should be tested against each and every affected
mission requirement for each relevant test scenario.

Service Delivery Specification items. Example: Specify payment
milestones, project administration and reporting requirements, schedule
of penalties, required maintenance response times, etc., as well as
requirements for project management plans, design reviews, installation
plans, etc. that are to be proposed by the vendor and finalized prior to
contract award.

Appendices (not part of the specification per se, but necessary to
support the procurement process).

> Examples:
>
> Proposal requirements;
>
> Proposal evaluation criteria;
>
> Background; and supporting information.

# Appendix E List of Contacts {#appendix-e-list-of-contacts .Closing}

+----------------------+----------------------+------------------------+
| **Agency Name**      | **Contact Name**     | **Phone**              |
+======================+======================+========================+
| **City, State**      | **Title**            | **E-Mail**             |
+----------------------+----------------------+------------------------+
| NJTRANSIT            | Mike Arthars         | 201-246-2259           |
+----------------------+----------------------+------------------------+
| Newark, NJ           | Director, TMAC       | [MArthars@njtr         |
|                      | Systems              | ansit.com]{.underline} |
+----------------------+----------------------+------------------------+
| King County Metro    | Michael Berman       | 206-263-3732           |
|                      |                      |                        |
| Seattle, WA          | GIS Program Manager  | <Micha                 |
|                      |                      | el.berman@metrokc.gov> |
|                      | Information          |                        |
|                      | Technology           |                        |
+----------------------+----------------------+------------------------+
| King County Metro    | Ellen Bevington      | 206-684-1953           |
+----------------------+----------------------+------------------------+
| Seattle, WA          | Supervisor of Speed  | <ellen.                |
|                      | and Reliability      | bevington@metrokc.gov> |
+----------------------+----------------------+------------------------+
| New Jersey Transit   | Joseph Bober         | 973-491-8555           |
| Corporation          |                      |                        |
+----------------------+----------------------+------------------------+
| Newark, NJ           | Chief of Police      | [jbober@njtr           |
|                      |                      | ansit.com]{.underline} |
+----------------------+----------------------+------------------------+
| Cubic Corporation    | Walt Bonneau, Jr.    | 858-505-2210           |
|                      |                      |                        |
| San Diego, CA        | Vice President       | <s                     |
|                      |                      | alt.bonneau@cubic.com> |
+----------------------+----------------------+------------------------+
| King County Metro    | Candace Carlson      | 206-684-1562           |
|                      |                      |                        |
| Seattle, WA          | Regional Fare        | <Candac                |
|                      | Collection Project   | e.carlson@metrokc.gov> |
|                      | Contract             |                        |
|                      | Administrator        |                        |
+----------------------+----------------------+------------------------+
| Synergist Technology | Gregory Cross        | 540-325-8997           |
| Group                |                      |                        |
|                      |                      | <its81@shentel.net>    |
| Edinburg, VA         |                      |                        |
+----------------------+----------------------+------------------------+
| SANDAG               | James                | 619-699-1914           |
|                      | Dreisbach-Towle      |                        |
| San Diego, CA        |                      | <jdr@sandag.org>       |
|                      | Administrator,       |                        |
|                      | Systems Integration  |                        |
+----------------------+----------------------+------------------------+
| Capital Metropolitan | Denise G. Du Charme  | \(512\) 369-6207       |
| Transportation       |                      |                        |
| Authority            | Manager, Information | <denise.               |
|                      | Technology           | ducharme@capmetro.org> |
| Austin, TX           |                      |                        |
+----------------------+----------------------+------------------------+
| MART                 | Bruno Fischer        | 978-345-7711           |
+----------------------+----------------------+------------------------+
| Fitchburg, MA        | Chief Operating      | <inf                   |
|                      | Officer              | o@MontachusettRTA.org> |
+----------------------+----------------------+------------------------+
| King County Metro    | Tom Friedman         | 206-684-1513           |
+----------------------+----------------------+------------------------+
| Seattle, WA          |                      | <tom                   |
|                      |                      | .friedman@metrokc.gov> |
+----------------------+----------------------+------------------------+
| Mentor Engineering,  | Brent Freet          | 403-777-3760, ext. 764 |
| Inc.                 |                      |                        |
|                      | Director of Sales    | <bfreer@mentoreng.com> |
| Calgary, AB, Canada  |                      |                        |
+----------------------+----------------------+------------------------+
| Orbital Sciences     | Marc Gordon          | 301-428-6535 x 6535    |
| Corp                 |                      |                        |
+----------------------+----------------------+------------------------+
| Columbia, MD         | Deputy General       | <Ma                    |
|                      | Manager,             | rc.gordon@orbital.com> |
|                      | Transportation       |                        |
|                      | Management Systems   |                        |
|                      | Division             |                        |
+----------------------+----------------------+------------------------+
| Bridgewater State    | Lawrence J. Harman,  | 508-531-6144           |
| College              | Co-Director          |                        |
|                      |                      | <lharman@bridgew.edu>  |
| Bridgewater, MA      | GeoGraphics          |                        |
| 02325                | Laboratory           |                        |
|                      |                      |                        |
|                      | Moakley Center for   |                        |
|                      | Technological        |                        |
|                      | Applications         |                        |
+----------------------+----------------------+------------------------+
| Utah Transit         | Richard Hodges       | 801-287-2354           |
| Authority            |                      |                        |
+----------------------+----------------------+------------------------+
| Salt Lake City, UT   | ITS Manager          | <                      |
|                      |                      | rhodges@uta.cog.ut.us> |
+----------------------+----------------------+------------------------+
| NJTRANSIT            | James Kemp           | 973-491-7861           |
+----------------------+----------------------+------------------------+
| Newark, NJ           | Manager, Data        | [jkemp@njtr            |
|                      | Coordination and     | ansit.com]{.underline} |
|                      | Integration          |                        |
+----------------------+----------------------+------------------------+
| Los Angeles County   | Paul Lennon          | 212-922-4418           |
| Metropolitan         |                      |                        |
| Transportation       |                      |                        |
| Authority            |                      |                        |
+----------------------+----------------------+------------------------+
| Los Angeles, CA      | Director of          | [lennonp@              |
|                      | Intelligence and     | metro.net]{.underline} |
|                      | Emergency            |                        |
|                      | Preparedness         |                        |
|                      | Management           |                        |
+----------------------+----------------------+------------------------+
| Advanced Transport   | Martin Lowson        | +44(0) 1454 414700     |
| Systems, LTD         |                      |                        |
+----------------------+----------------------+------------------------+
| UK                   | President            | [martin@l              |
|                      |                      | owson.net]{.underline} |
+----------------------+----------------------+------------------------+
| Capital Area Rural   | David L. Marsh       | 512-481-1011           |
| Transportation       |                      |                        |
| System (CARTS)       | General Manager      | <Dave@RideCARTS.com>   |
|                      |                      |                        |
| Austin, TX           |                      |                        |
+----------------------+----------------------+------------------------+
| Washington           | J. F. Peter Meenehan | \(202\) 962-3200       |
| Metropolitan Area    |                      |                        |
| Transit Authority    | IT Project Manager,  | <jmeenehan@wmata.com>  |
|                      | ITS Coordinator      |                        |
| Washington, DC       |                      |                        |
+----------------------+----------------------+------------------------+
| Siemens VDO          | Andreas Meyer        | +41 44 977 1890        |
| Automotive AG        |                      |                        |
+----------------------+----------------------+------------------------+
| Switzerland          |                      | [a.meyer@b             |
|                      |                      | luewin.ch]{.underline} |
+----------------------+----------------------+------------------------+
| King County Metro    | Dan Overgaard        | \(206\) 684-1415       |
| Transit              |                      |                        |
|                      | Supervisor of        | <dan.                  |
| Seattle, WA          | Systems Management   | overgaard@metrokc.gov> |
|                      | and Analysis         |                        |
+----------------------+----------------------+------------------------+
| Argonne National     | Anthony Policastro   | 630-252-3235           |
| Laboratory           |                      |                        |
+----------------------+----------------------+------------------------+
| Argonne, IL          | Project Manager,     | [policastr             |
|                      | PROTECT              | o@anl.gov]{.underline} |
+----------------------+----------------------+------------------------+
| Maryland Transit     | Erin Purdy           | 410-454-7292           |
| Administration       |                      |                        |
|                      | Mobility             | <e                     |
| Baltimore, MD        | Services             | purdy@mtamaryland.com> |
+----------------------+----------------------+------------------------+
| NJTRANSIT            | Andrew Schwartz      | 973-491-7745           |
+----------------------+----------------------+------------------------+
| Newark, NJ           | Director, Radio      | [Aschwartz@njtr        |
|                      | Systems              | ansit.com]{.underline} |
+----------------------+----------------------+------------------------+
| Trapeze ITS          | Greg Tomsic          | 319-398-4102           |
+----------------------+----------------------+------------------------+
|                      | General Manager and  | [gtomsic@tr            |
|                      | Vice President       | apeze.com]{.underline} |
+----------------------+----------------------+------------------------+
| Oak Ridge National   | Tykey Truett         | 865-946-1306           |
| Laboratory           |                      |                        |
|                      | Energy Division\'s   | <TurettLF@ORNL.gov>    |
| Oak Ridge, TN        | Center for           |                        |
|                      | Transportation       |                        |
|                      | Analysis             |                        |
+----------------------+----------------------+------------------------+
| King County Metro    | Wayne Watanabe       | 206-684-1633           |
| Transit              |                      |                        |
|                      | Supervisor for       | <wayne                 |
| Seattle, WA          | Infrastructure and   | .watanabe@metrokc.gov> |
|                      | Integration          |                        |
+----------------------+----------------------+------------------------+
| Tri-Met              | Bibiana Kamler       | 503-962-7536           |
|                      | McHugh               |                        |
+----------------------+----------------------+------------------------+
| Portland, OR         | IT Manager, GIS and  | [mchughb@t             |
|                      | Location Based       | rimet.org]{.underline} |
|                      | Services             |                        |
+----------------------+----------------------+------------------------+
| Tri-Met              | Ron White, Rick      | 503-962-5877, ext.     |
|                      | Jacobi, Network      | 5866                   |
|                      | Engineers            |                        |
+----------------------+----------------------+------------------------+
| Portland, OR         | IT Department,       | [jacobir@t             |
|                      | Network              | rimet.org]{.underline} |
|                      | Communications Group |                        |
+----------------------+----------------------+------------------------+

[^1]: "Shared Communications: Volume I. A Summary and Literature
    Review," by Oscar Franzese, Tykey Truett, and Edmond Chin-Ping
    Chang, was completed in 2004.

[^2]: *Ibid*.

[^3]: From "Turning Transportation On," published in *Intelligence and
    Warning America* in March 2004.
    [www.netscout.com/docs/reprints/NetScout_reprint_IWA_Turning_Transport_On.pdf](http://www.netscout.com/docs/reprints/NetScout_reprint_IWA_Turning_Transport_On.pdf).

[^4]: For example, Technology Solution Providers' "Assessment of ITS
    Deployments: Draft Final Report." The importance of managing
    institutional issues is also discussed in "Shared Communications:
    Volume I. A Summary and Literature Review," by Oscar Franzese, Tykey
    Truett, and Edmond Chin-Ping Chang.

[^5]: See ITS Architecture Implementation Program information from the
    USDOT at:
    [www.ops.fhwa.dot.gov/its_arch_imp/index.htm](http://www.ops.fhwa.dot.gov/its_arch_imp/index.htm).

[^6]: Additional information about the National ITS Architecture is
    described at the following site:
    [www.iteris.com/itsarch/index.htm](http://www.iteris.com/itsarch/index.htm).

[^7]: At the time of this report, no ITS standards have been officially
    adopted by the USDOT.

[^8]: The full title of the guidebook is \"Defining Geographic Locations
    of Bus Stops, Routes and Other Map Data for ITS, GIS and Operational
    Efficiencies: Best Practices for Using Geographic Data in Transit: A
    Location Referencing Guidebook." See Bibliography for Integration.

[^9]: From "Building Quality Intelligent Transportation Systems Through
    Systems Engineering." See Bibliography for Integration.

[^10]: From Steven H. Spewak, Steven C. Hill, [Enterprise Architecture
    Planning: Developing a Blueprint for Data, Applications, and
    Technology]{.underline}, September 1993.

[^11]: From *A Practical Guide to Enterprise Architecture Version 1.0 --
    Federal Council of Chief Information Officers* (February 2001). See
    also,
    <https://secure.cio.noaa.gov/hpcc/docita/files/federal_enterprise_arch_framework.pdf>.

[^12]: [www.itsdeployment.its.dot.gov/download.asp#surveysummary](http://www.itsdeployment.its.dot.gov/download.asp#surveysummary).

[^13]: Examples from ITS regional architectures are linked at the
    following Web site:
    [www.ops.fhwa.dot.gov/its_arch_imp/examples.htm](http://www.ops.fhwa.dot.gov/its_arch_imp/examples.htm).

[^14]: "Developing, Using, and Maintaining an ITS Architecture for Your
    Region," prepared by the National ITS Architecture Team, October 12,
    2001.

[^15]: [www.itslessons.its.dot.gov/its/benecost.nsf/DisplayLessonByStateSingle?OpenFormandState=Iowa](http://www.itslessons.its.dot.gov/its/benecost.nsf/DisplayLessonByStateSingle?OpenForm&State=Iowa).

[^16]: Image originally developed in 2001 by Michael Berman, King County
    Metro.

[^17]: From a discussion with Dan Overgaard and Bob Syslo-Seel, King
    County Metro Transit.

[^18]: From correspondence with Bibiana McHugh, GIS Manager at Tri-Met.

[^19]: From a discussion and presentation prepared by Peter Meenehan,
    WMATA.

[^20]: Presentation from WMATA.

[^21]: According to the 2003 Transit GIS Survey, 74% of the 77 transit
    agencies that responded are using GIS. The survey results can be
    found at
    [www.e-transit.org/survey/20022003/](http://www.e-transit.org/survey/20022003/).

[^22]: See Section 6.4.5, Building a Location Table, in the guidebook,
    \"Defining Geographic Locations of Bus Stops, Routes and Other Map
    Data for ITS, GIS and Operational Efficiencies: Best Practices for
    Using Geographic Data in Transit: A Location Referencing Guidebook."

[^23]: The size of dot in the figure reflects the relative number of
    boardings at that bus stop.

[^24]: [http://geolab.bridgew.edu/home/.](http://geolab.bridgew.edu/home/)

[^25]: [www.wmata.com/maps/metrorail_street_map.cfm](../www.wmata.com/maps/metrorail_street_map.cfm).

[^26]: [www.metrokc.gov/gis/Projects/TNET/tnet_consortium.htm](http://www.metrokc.gov/gis/Projects/TNET/tnet_consortium.htm).

[^27]: It is part of an intergovernmental project managed by the
    Department of the Interior in support of the President\'s Initiative
    for E-government. See the Web site at
    [www.geo-one-stop.gov](http://www.geo-one-stop.gov/).

[^28]: Summary information on the standard is available at
    [www.standards.its.dot.gov/StdsSummary.asp?ID=419](http://www.standards.its.dot.gov/StdsSummary.asp?ID=419).

[^29]: "Transit Communications Interface Profiles. Draft Standard
    Version 2.7.1" Section 5.10, Concept of Operations for the Spatial
    Data Management Process, APTA, 2005.

[^30]: If the appropriate associations are made between the features and
    data elements.

[^31]: Titled \"Defining Geographic Locations of Bus Stops, Routes and
    Other Map Data for ITS, GIS and Operational Efficiencies: Best
    Practices for Using Geographic Data in Transit: A Location
    Referencing Guidebook."

[^32]: LAN or WAN infrastructures, using Internet protocols, are often
    referred to as Intranet and Extranet, respectively.

[^33]: Information provided by City of Seattle.

[^34]: "DSRC Technology and the DSRC Industry Consortium (DIC) Prototype
    Team." SIRIT Technologies, January 28, 2005. 8 pp.

[^35]: Walker, Jonathan, "[Wi-Fi  Mesh Networks: The Path to Mobile Ad
    Hoc](http://www.wi-fitechnology.com/Wi-Fi_Reports_and_Papers/Wi-Fi_Mesh_Networks.html),"\
    www.wi-fitechnology.com/Wi-Fi_Reports_and_Papers/Introduction_to_Wi-Fi_Mesh_Networks.html.

[^36]: A T-1 line is a dedicated phone line supporting data rates of
    1.544 Mbits per second and that has 24 individual channels, each of
    which can be configured to carry voice or data.

[^37]: *City Buses Pick Up Wireless Broadband in Cedar Rapids*,
    Broadband Wireless Exchange Magazine, September 14, 2005,
    [www.bbwexchange.com/publications/page1387-2994932.asp](http://www.bbwexchange.com/publications/page1387-2994932.asp).

[^38]: Information for this section was provided by LAC METRO staff.

[^39]: [www.dot.ca.gov/hq/research/operations/edapts/edapts.htm](http://www.dot.ca.gov/hq/research/operations/edapts/edapts.htm).

[^40]: DeGraff, Kenneth, "Community Wireless Network: Why Not?" *Mobile
    Government: Point/Counterpoint, A Supplement to Government
    Technology*, June 2005, pp. 7-9.

[^41]: Watje, John, and Bill Kronenberger, "Data Communications Network
    for Transit Vehicles: SAE J1708 Serial Data Communications between
    Microcomputer Systems in Heavy Duty Vehicle Applications." In
    *Transit ITS Compendium*, Wilson, Lawrence, ed. Institute of
    Transportation Engineers, Washington, DC, 1997, pp. 34-38.

[^42]: Other standards activities have been ongoing at APTA such as
    PRESS as well as around the world to address ITS and other
    standards.

[^43]: IEEE rail standards are discussed in the context of rail systems
    in Chapter 8 -- Intelligent Vehicle Systems.

[^44]: The following UTFS Committee descriptions are excerpted from Tam,
    Chung Chung, "Chung-Chung Tam --- Cartes 2005 Revised 09-10-2005."

[^45]: Ibid. \[Tam, 2005\]

[^46]: Refers to Level 3 in the Electronic Fare System Architecture
    Figure 4-xx.

[^47]: Refers to Level 2 in the Electronic Fare System Architecture
    Figure 4-xx.

[^48]: Refers to Level 3 in the Electronic Fare System Architecture
    Figure 4-xx.

[^49]: Refers to Level 4 in the Electronic Fare System Architecture
    Figure 4-xx.

[^50]: Differences between UTFS vs. TCIP. UTFS is an end-to-end
    integrated fare management process for electronic media (magnetic
    and integrated circuit cards) that supports regional payment
    management systems. On the other hand, TCIP serves a single operator
    only for fare boxes on board buses. A comparison of the two is
    described in the table below.

[^51]: The term SOAP is no longer used as an acronym to mean "simple
    object application protocol."

[^52]: Transmodel site: [www.transmodel.org](http://www.transmodel.org/)
    or background information on http:
    [www.transmodel.org.uk/.](../www.transmodel.org.uk/)

[^53]: Intelligent Transportation Systems Technology Overview, US
    Department of Transportation, ITS Joint Program Office, Washington,
    DC, 2005.
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=TMandSubSystem=FMandTech=AVL](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=TM&SubSystem=FM&Tech=AVL).

[^54]: op. cit.
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=TMandSubSystem=FMandTech=Maintenance](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=TM&SubSystem=FM&Tech=Maintenance).

[^55]: op. cit.
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=TMandSubSystem=FMandTech=Planning](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=TM&SubSystem=FM&Tech=Planning).

[^56]: Intelligent Transportation Systems Technology Overview, US
    Department of Transportation, ITS Joint Program Office, Washington,
    DC. 2005.
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=AMandSubSystem\
    =TCandTech=Priority](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=AM&SubSystem=TC&Tech=Priority).

[^57]: Best Practices Procurement Manual, Federal Transit
    Administration, Washington, DC, revised October 2005,
    [www.fta.dot.gov/9386_ENG_HTML.htm](http://www.fta.dot.gov/9386_ENG_HTML.htm).

[^58]: National ITS Architecture Web site, US Department of
    Transportation, Washington DC, <http://itsarch.iteris.com/itsarch/>.

[^59]: An "electronic purse" stores prepaid monetary value.

[^60]: The smart card is accepted and used by more people in more
    markets, such as transportation, retail and municipal services.

[^61]: ORANGES Evaluation Phase I Risk Assessment Report, by US
    DOT/Volpe, March 11, 2004.
    [www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/13966.html](http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/13966.html).

[^62]: See [www.translink.org](http://www.translink.org/).

[^63]: Information on Maryland Transit Administration's Taxi Access
    program for MTA Mobility participants can be found at:
    [www.taxiaccess.org/](http://www.taxiaccess.org/).

[^64]: From October 2005 presentation titled "UTA Approach to Electronic
    Fare Collection" by D. Craig Roberts.

[^65]: From "Northern Shenandoah Valley Public Mobility Program,"
    Gregory Cross, Program Manager, October 2005.

[^66]: Federal Health Insurance Portability and Accountability Act.

[^67]: Crotch-Harvey, Trevor, "Limited Use Smart Tickets," APTA Fare
    Collection Workshop, Oakland, March 23, 2005.

[^68]: [www.smartcardalliance.org/alliance_activities/who_what_why_contactless_payments.cfm](http://www.smartcardalliance.org/alliance_activities/who_what_why_contactless_payments.cfm).

[^69]: [www.smartcardalliance.org/pdf/alliance_activities/Contactless_Payments_Position.pdf](http://www.smartcardalliance.org/pdf/alliance_activities/Contactless_Payments_Position.pdf).

[^70]: [www.publictransportation.org/media/release050908.asp](http://www.publictransportation.org/media/release050908.asp).

[^71]: UTFS Task Force Financial Management Committee Business Process
    Work Group, "The Major Business Issues in Establishing and Operating
    Regional Transportation Payment Systems and Clearinghouses." APTA,
    Version 2.01, edited September 20, 2004.

[^72]: From "Major Business Issues," p.14.

[^73]: From MTA, p.2.

[^74]: "From Major Business Issues," pp. 14-39.

[^75]: [www4.trb.org/trb/crp.nsf](http://www4.trb.org/trb/crp.nsf).

[^76]: TCRP Project A-26, Smartcard Interoperability, Draft Report
    scheduled to be issued in fall 2005.

[^77]: As reported in the "Assessment of ITS Deployments - Draft Final
    Report," Technology Solution Providers, May 2005.

[^78]: [www.toronto.ca/ttc/pdf/fare_collection_report_2000.pdf](http://www.toronto.ca/ttc/pdf/fare_collection_report_2000.pdf).

[^79]: A Transit Cooperative Research Board report titled "Real-Time Bus
    Arrival Information Systems: A Synthesis of Transit Practice, Report
    #48," provides an overview.

[^80]: [www.dundeetravelinfo.com](http://www.dundeetravelinfo.com/).

[^81]: See:
    [www.sei.cmu.edu/opensystems/faq.html](http://www.sei.cmu.edu/opensystems/faq.html).
    This Web site provides a comprehensive description of open systems,
    standards, and interoperability issues.

[^82]: Data maintenance is greatly simplified when the location
    reference methods of multiple features only have to be updated in a
    single table. Another key advantage is the ability to remove the
    spatial requirement from other independent applications while
    linking them back to a robust and comprehensive spatial description.
    Applications that are largely tabular in nature do not need to have
    the added requirement of spatial tools and their associated
    licensing fees, yet can still be tied back to the spatial world
    through a simple location ID reference.

[^83]: FTA funded the development of a guidebook that identifies issues,
    benefits, and options pertaining to base maps and the spatial
    definition of transit features such as routes, stops, and
    timepoints. The guidebook is titled, \"Defining Geographic Locations
    of Bus Stops, Routes and Other Map Data for ITS, GIS and Operational
    Efficiencies: Best Practices for Using Geographic Data in Transit: A
    Location Referencing Guidebook" (Transit Standards Consortium,
    October 2003, <http://tsconsortium.org/LRG_FinalPublication.pdf>).

[^84]: Staff at Capital Metro in Austin stated that knowing when and
    where customers "give up" and exit the system is helpful for
    designing improvements. Using markers at the exit points and
    tracking software can expedite troubleshooting.

[^85]: The "Bus Stop Inventory Guidebook," (Transit Standards
    Consortium, August 2000.
    [[http://tsconsortium.org/BusStopInventoryBestPracticesandGuidlines.pdf]{.underline}](http://tsconsortium.org/BusStopInventoryBestPractices&Guidlines.pdf))
    is an excellent resource that identifies a wide range of bus stop
    related issues and solutions.

[^86]: From discussion of the Arizona 511 Model Deployment on the
    Talking Operations forum on "Rural Issues: 511 and Traveler
    Information," on July 27, 2005,
    [[www.ntoctalks.com]{.underline}](http://www.ntoctalks.com/).

[^87]: See: Transportation Research Board Research in Progress: *Safety
    and Security Technology Transfer Support*,
    <http://rip.trb.org/browse/dproject.asp?n=9381>, 2002-ongoing.

[^88]: T. Littman's article, "Lessons From Katrina: What a Major
    Disaster Can Teach Transportation Planners," points out how failures
    in planning and the breakdown in communications among public
    agencies compounded the disaster in New Orleans in August-September
    2005.

[^89]: See Section 6.6.1, NJ Transit example of expanding its video
    assessment system to include external partners.

[^90]: See "Telecommunications Systems---Radio Systems" in TRB\'s
    Transit Cooperative Research Program (TCRP) Report 43:
    "Understanding and Applying Advanced On-Board Electronics, pp.
    17-18.

[^91]: An inventory of radio communications systems compiled by Orbital
    Systems is provided at
    [www.tms-online.com/projects_transit_index.html](http://www.tms-online.com/projects_transit_index.html).
    Lack of standardization is apparent in the survey results.

[^92]: See: Department of Homeland Security SAFECOM program information
    at:
    [www.dhs.gov/dhspublic/interapp/editorial/editorial_0339.xml](http://www.dhs.gov/dhspublic/interapp/editorial/editorial_0339.xml)
    and a review of the program's status by the Government
    Accountability Office at
    [www.gao.gov/new.items/d04494.pdf](http://www.gao.gov/new.items/d04494.pdf);
    State of Texas, Radio Communications Interoperability Plan at
    [www.atcog.org/Tx%20Radio%20Communications%20Interoperability%20Plan.doc](http://www.atcog.org/Tx Radio Communications Interoperability Plan.doc).

[^93]: See general descriptions of CapWIN at:
    [www.capwin.org/](http://www.capwin.org/).

[^94]: Again, the potential gains from the innovative, mobile broadband
    communications system in this case would be significant. For recent
    and latest updates on this rapidly evolving technology, see
    <http://zdnet.search.com/search?q=mobile+broadband>,
    [www.spectrum.ieee.org/WEBONLY/resource/jun05/0605ntv.html](http://www.spectrum.ieee.org/WEBONLY/resource/jun05/0605ntv.html),
    and
    [www.spectrum.ieee.org/WEBONLY/resource/sep05/0905nkor.html](http://www.spectrum.ieee.org/WEBONLY/resource/sep05/0905nkor.html).

[^95]: Portland Tri-Met has been aggressive in planning for and
    accommodating the deployment of ITS technology on its information
    technology infrastructure. See article at:
    [www.netscout.com/docs/reprints/NetScout_reprint_IWA_Turning_Transport_On.pdf](http://www.netscout.com/docs/reprints/NetScout_reprint_IWA_Turning_Transport_On.pdf).

[^96]: Shortly after 9/11, transit agencies gathered in a series of
    "Connecting Communities" workshops sponsored by the Federal Transit
    Administration ([http://transit-
    safety.volpe.dot.gov/training/Archived/EPSSeminarReg/default.asp](http://transit-safety.volpe.dot.gov/training/Archived/EPSSeminarReg/default.asp))
    and determined that transit response to the then-Office of Homeland
    Security's Threat Level Response Recommendation should include two
    additional categories above "Code Red": Black would indicate "Under
    Attack" and Purple would indicate "Recovery." Incident response
    would therefore be considered the activities related to Code Black.
    See:
    <http://transit-safety.volpe.dot.gov/security/SecurityInitiatives/ThreatLevel/default.asp>.

[^97]: <http://www.deploy511.org/>.

[^98]: <http://www.transitinfo.org/index.asp>.

[^99]: Seattle King County Metro and Miami-Dade Transit are two
    examples.

[^100]: See sample list of incident and disaster planning support
    systems software at:
    [www.drj.com/vendor/drj5.html](http://www.drj.com/vendor/drj5.html).

[^101]: "A Toolbox for Alleviating Traffic Congestion," Institute of
    Transportation Engineers, Washington, DC, 1989, p.107.

[^102]: Hattum, David Van, "TDM Guidebook --- Expanding Commuter Options
    in the Twin Cities: Practical and Cost-Effective Steps to Reduce
    Congestion by Optimizing Travel Demand Management (TDM) Strategies,"
    494 Commuter Services.

[^103]: Ibid.

[^104]: Ibid.

[^105]: Ibid.

[^106]: Transportation Demand Management User Service, National ITS
    Architecture, US Department of Transportation, Washington, DC, 2005,
    [www.iteris.com/itsarch/html/user/usr18.htm](http://www.iteris.com/itsarch/html/user/usr18.htm).

[^107]: Ibid.

[^108]: Institute of Transportation Engineers, op. cit.

[^109]: Ibid.

[^110]: Hattum, op. cit.

[^111]: Ibid.

[^112]: Ibid.

[^113]: Institute of Transportation Engineers, op. cit., p. 120.

[^114]: Op. cit., p. 122.

[^115]: Op. cit., p. 115.

[^116]: Op. cit., p. 114.

[^117]: Op. cit., p. 112.

[^118]: Op. cit., p. 108.

[^119]: www.transitcenter.com/.

[^120]: It should be noted that elements of various other ITS
    application areas, most notably traveler information, traffic
    control, electronic payment, fleet management, in-vehicle guidance,
    and the ITS data warehouse, when used effectively, may also support
    transportation demand management. These applications are typically
    not intended primarily for TDM, however, and so are addressed
    elsewhere in this report.

[^121]: Ride sharing is the act of sharing a vehicle with one or more
    other people.

[^122]: Ride matching is the process of pairing prospective passengers
    with available drivers with common origins or destinations.

[^123]: Personal Rapid Transit (PRT) is theoretically a highly efficient
    [transport](http://en.wikipedia.org/wiki/Transport) method that
    offers unscheduled on-demand nonstop transportation between any two
    points on an interlaced network of specially built guideways, using
    small (1-6 person) cars that follow mathematically optimized
    trajectories from point to point. (Wikipedia,
    <http://en.wikipedia.org/wiki/Personal_rapid_transit>).

[^124]: Many airport shuttle services operate in this fashion.

[^125]: In a subscription service, the ride matching process is
    accomplished well in advance of the trip; typically the subscription
    is for multiple repeated trips to/from the same location.

[^126]: (Wikipedia,
    <http://en.wikipedia.org/wiki/Personal_rapid_transit>).

[^127]: "APTS State of the Art Update 2005" Web survey, Palisades
    Consulting Group, 2005.

[^128]: <http://www.its.dot.gov/resources/IntegrationProject/projects/PTO-72.htm>

[^129]: Battelle Memorial Institute, "Evaluation of Utah Transit
    Authority's Connection Protection System, Final Project Report,"
    FHWA, document 14074, May 2004.
    [www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE//14074.htm](http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE//14074.htm).

[^130]: USDOT, "AATA AOS Evaluation -- Transfer and On Time Performance
    Study: Before and After AOS Implementation."
    [www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/13147.pdf](http://www.itsdocs.fhwa.dot.gov/jpodocs/repts_te/13147.pdf).

[^131]: Examples include MTA Metro North and Long Island Railroads in
    New York City, NY.

[^132]: APTS State of the Art Update 2005 web survey, Palisades
    Consulting Group, 2005

[^133]: USDOT, ITS Deployment Statistics 2004 --- Utah Transit
    Authority.
    [http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TMandAgencyID=1590](http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TM&AgencyID=1590).

[^134]: USDOT, ITS Deployment Statistics 2004 --- Ann Arbor Transit
    Authority.
    [http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TMandAgencyID=552](http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TM&AgencyID=552).

[^135]: ITS International, "Star of the Lone Star State," Kent, UK,
    2005.

[^136]: Nationwide, 12 of 106 metropolitan areas surveyed report use of
    dynamic message signs to display parking information at one or more
    individual lot locations (ITS deployment survey 2004;
    <http://itsdeployment2.ed.ornl.gov/its2004/Results.asp?ID=971>.)

[^137]: Palisades, op. cit.

[^138]: ODOT Trip Check,
    [www.tripcheck.com/Pages/BusRailEntry.asp](http://www.tripcheck.com/Pages/BusRailEntry.asp).

[^139]: [www.wsdot.wa.gov/](http://www.wsdot.wa.gov/).

[^140]: [www.rtd-denver.com/](http://www.rtd-denver.com/).

[^141]: Chicago RTA, ITS Program, Parking Management Guidance System
    (PMGS),
    [www.rtachicago.com/CMS200Sample/uploadedFiles/its%20for%20web%20FINAL.pdf](http://www.rtachicago.com/CMS200Sample/uploadedFiles/its for web FINAL.pdf).

[^142]: Battelle, op. cit.

[^143]: Ibid.

[^144]: *American Heritage Dictionary*, Houghton Mifflin Company,
    Boston, MA, 1985.

[^145]: "Consumer Acceptance of Automotive Crash Avoidance Devices,"
    Charles River Associates, Boston, MA, 1998.

[^146]: Assessment of ITS Deployments, Technology Solution Providers,
    FTA DTFT60-03-00012, Arlington, TX, 2005, Table 4.

[^147]: Ibid.

[^148]: Intelligent Transportation Systems Deployment Statistics, US
    Department of Transportation, ITS Joint Program Office, Washington,
    DC, 2004,
    [http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TMandAgencyID=1756](http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TM&AgencyID=1756).

[^149]: Assessment of ITS Deployments, Technology Solution Providers,
    FTA DTFT60-03-00012, 2005, Table 4.

[^150]: ibid.

[^151]: Intelligent Transportation Systems Deployment Statistics, US
    Department of Transportation, ITS Joint Program Office, Washington,
    DC, 2004,
    [http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TMandAgencyID=409](http://itsdeployment2.ed.ornl.gov/its2004/AdminViewSurvey.asp?SSN=TM&AgencyID=409).

[^152]: APTS State of the Art Update 2005 web survey, Palisades
    Consulting Group, 2005.

[^153]: ibid.

[^154]: On-Board Digital Video Recording specification, New Jersey
    Transit Corporation, 2005.

[^155]: Intelligent Transportation Systems Technology Overview, U.S.
    Department of Transportation, ITS Joint Program Office, Washington,
    DC, 2005. [http://itsdeployment2.ed.ornl.gov/technology_overview/\
    Options.asp?System=CWS&SubSystem=RDW&Tech=Road](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWS&SubSystem=RDW&Tech=Road).

[^156]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/\
    Options.asp?System=CWSandSubSystem=LDWandTech=Lane](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWS&SubSystem=LDW&Tech=Lane).

[^157]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/\
    Options.asp?System=CWSandSubSystem=RWandTech=Rollover](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWS&SubSystem=RW&Tech=Rollover).

[^158]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/\
    Options.asp?System=DASandSubSystem=RSCandTech=Roll](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DAS&SubSystem=RSC&Tech=Roll).

[^159]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/\
    Options.asp?System=CWSandSubSystem=RIWandTech=Rear](http://itsdeployment2.ed.ornl.gov/technology_overview/%0BOptions.asp?System=CWSandSubSystem=RIWandTech=Rear).

[^160]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWSandSubSystem=ODandTech=Obstacle](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWS&SubSystem=OD&Tech=Obstacle).

[^161]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWSandSubSystem=LCandTech=Lane](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWS&SubSystem=LC&Tech=Lane).

[^162]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWSandSubSystem=ICWandTech=Intersection](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWS&SubSystem=ICW&Tech=Intersection).

[^163]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWSandSubSystem=FCWandTech=Forward](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CWS&SubSystem=FCW&Tech=Forward).

[^164]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CNSandSubSystem=AAandTech=Advanced](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=CNS&SubSystem=AA&Tech=Advanced).

[^165]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DASandSubSystem=DDWSandTech=Drowsy](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DAS&SubSystem=DDWS&Tech=Drowsy).

[^166]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DASandSubSystem=VEandTech=Vision](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DAS&SubSystem=VE&Tech=Vision).

[^167]: National ITS Architecture, Pre-Crash Restraint Deployment User
    Service, US Department of Transportation, Washington, DC, 2005.
    [www.iteris.com/itsarch/html/user/usr66.htm](http://www.iteris.com/itsarch/html/user/usr66.htm).

[^168]: Intelligent Transportation Systems Technology Overview,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DASandSubSystem=ICCandTech=Intelligent](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DAS&SubSystem=ICC&Tech=Intelligent).

[^169]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DASandSubSystem=NandTech=Navigation](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DAS&SubSystem=N&Tech=Navigation).

[^170]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DASandSubSystem=PDandTech=Precision](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DAS&SubSystem=PD&Tech=Precision).

[^171]: Op. cit.,
    [http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DASandSubSystem=LKAandTech=Lane](http://itsdeployment2.ed.ornl.gov/technology_overview/Options.asp?System=DAS&SubSystem=LKA&Tech=Lane).

[^172]: Multimodal Vehicle Assist and Automation; VAA Systems for
    Transit Operations, Hardy and Proper, Mitretec Systems, Washington,
    DC, 2005.

[^173]: Bus Rapid Transit Lane Assist Technology Systems, Metro Transit
    and University of Minnesota, Minneapolis, MN, 2003, p. 23.
    [www.its.umn.edu/research/applications/brt/laneassist/LAfinal1.pdf](http://www.its.umn.edu/research/applications/brt/laneassist/LAfinal1.pdf).

[^174]: Ibid.

[^175]: Hardy and Proper, op. cit.

[^176]: Consumer Acceptance of Automotive Crash Avoidance Devices, op.
    cit.