Recognize that interoperability is becoming an important issue in achieving the vision of a nationwide 511 system.

A national experience with the development and deployment of 511 Systems.

Date Posted

Implementation and Operational Guidelines for 511 Services, Version 2.0

Summary Information

In March of 1999, the U.S. Department of Transportation (USDOT) petitioned the Federal Communications Commission (FCC) to designate a nationwide three-digit telephone number for traveler information. In July 2001, the FCC designated 511 as the national traveler information number. As of July 2003, nineteen 511 services across the country are operational and many have learned valuable lessons on deploying and operating systems.

In early 2001, the American Association of State Highway and Transportation Officials (AASHTO), the American Public Transportation Association (APTA), and the Intelligent Transportation Society of America (ITS America) with the support of the USDOT established a 511 Deployment Coalition. The goal of the Coalition is that 511 will be a “customer driven multi-modal traveler information service, available across the United States, accessed via telephones and other personal communications devices, realized through locally deployed interoperable systems, enabling a safer, more reliable and efficient transportation system.” In September 2003, the Coalition published the Implementation and Operational Guidelines for 511 Services, Version 2.0 to assist implementers in developing quality systems and increasing the level of operational knowledge among the 511 community. The lesson below is gathered from this guide, which has captured the experiences from many of the existing 511 services nationwide.

Lessons Learned

511 system deployers should recognize that interoperability is becoming an important issue in achieving the vision of a nationwide 511 System and consider ways to achieve interoperability in their system. Interoperability deals with how 511 services with adjacent operating borders provide seamless information to the system users. A growing number of 511 systems share boundaries and / or have significant travel in-between them. This is also true along major travel corridors throughout the country. Callers in one metropolitan area may wish to dial 511 to find information not just for their local travels, but for their entire trip, which might include traveling through other metropolitan areas or regions and crossing state borders. As the number of 511 services available increase in many areas of the country, it is believed that users will have an expectation that information relating to areas outside of their region will be available in a single call.

Currently, interoperability is being approached in different ways by deployers. This will help provide the 511 services still in the planning stage with insight and lessons as to the best, most applicable, solution given a certain set of technical and financial circumstances. As an example since December 2002, the metropolitan Cincinnati system (ARTIMIS) has been successfully passing Kentucky suburban incident information into the Kentucky statewide Condition Acquisition Reporting System (CARS-511) using Traffic Management Data Dictionary (TMDD) ITS standards, implemented in Traveler Information Markup Language (TIML) / eXtensible Markup Language (XML). Kentucky traffic events reported in ARTIMIS are imported to the CARS-511 system for fully automated reporting without any manual data re-entry. Although the two 511 systems were developed at different times and independently, the standards are allowing seamless data exchange as no call transfers or manual processing are necessary [1] .

The following general system design considerations from the Implementation and Operational Guidelines for 511 Systems Version 2.0 are provided as issues to consider.

  • Identify travel corridors. Consider local, regional and corridor travel that require information presentation on their 511 system.
  • Maintain coordination with bordering jurisdictions. Recognize that your neighbors will also be dealing with the same issues and their cooperation and coordination is essential to implementing a successful system.
  • Use standards when developing system. The SAE ATIS (J2354) standard has many important components for 511 systems, including transit information and vehicle routing. The example provided above in metropolitan Cincinnati showed how two systems developed at different times were able to provide seamless data exchange because standards were implemented.
  • Examine and understand wireless calling areas. Develop a plan for dealing with mis-routed calls at the boundary of your system.
  • Encourage telecommunications carriers to develop service offerings for 511 access that can be implemented in multiple jurisdictions. Implementing in multiple jurisdictions will ease the task of 511 deployment by communities other than the “early implementers.” An example of this was presented in the San Francisco 511 Case Study: MTC's efforts to implement 511 access swiftly have been frustrated to some extent by the understandable need of Pacific Bell to develop its plans for offering 511 access in tandem with planning by its parent company, SBC, and its sister telecommunications carriers within the SBC corporate family. While SBC's measured approach to developing a system wide "preferred solution" has undoubtedly been a source of frustration for MTC, it offers a potential advantage for local governments outside the San Francisco Bay Area that are served by Pacific Bell or other SBC affiliates. By the time those governments are ready to implement 511 access for their traveler information services, SBC's preferred solution will have been tested and deployed and any start-up problems likely will have been cured. It makes sense for government agencies, at local, state, and federal levels, to encourage telecommunications carriers to develop 511 access solutions that can be replicated throughout their service areas, and to find ways to distribute the cost of developing those solutions fairly among the "early implementers" like MTC and those local agencies that are slower to put 511 access in place[2].

As seen in the San Francisco Bay Area case study, working to deploy an interoperable system may have created some early implementation delays, however the advantages of developing a region wide 511 system that has been tested and deployed will reduce the implementation schedule for other agencies as they prepare to implement a 511 system and will help to more equally distribute the development costs among all the system implementers.

This lessons suggests that callers will have an expectation that information relating to areas outside of their region will be available in a single call, therefore 511 developers need to recognize the importance of interoperability and look beyond their borders to make 511 a success with the traveling public. Without system operability there is numerous independent 511 systems scattered throughout the country and this is not what the Federal Communications Commission (FCC) or the 511 Deployment Coalition envisioned. It fails to meet the national vision and the Coalition’s goals of providing a safer, more reliable and efficient transportation system. For the vision to become a reality, callers need to be able to get information from areas outside the local 511 system requiring interoperability of systems at the local level.

[1] Deployment Assistance Report #4 511 Regional Interoperability Issues, March 2003

[2] San Francisco 511 Case Study