Information services in social networked transportation : governance and ITS

GEORGIA DOT RESEARCH PROJECT 12-26 FINAL REPORT
INFORMATION SERVICES IN SOCIAL NETWORKED TRANSPORTATION: GOVERNANCE AND ITS
OFFICE OF RESEARCH

This page intentionally left blank.

GDOT Research Project RP12-26
Final Report
INFORMATION SERVICES IN SOCIAL NETWORKED TRANSPORTATION: GOVERNANCE AND ITS
By Dr. Hans Klein Associate Professor School of Public Policy Georgia Institute of Technology
Dr. Kari E. Watkins Assistant Professor School of Civil and Environmental Engineering Georgia Institute of Technology
Contract with Georgia Department of Transportation
In cooperation with U.S. Department of Transportation
Federal Highway Administration June 2014
The contents of this report reflect the views of the author(s) who is (are) responsible for the facts and the accuracy of the data presented herein. The contents do not necessarily reflect the official views or policies of the Georgia Department of
Transportation or the Federal Highway Administration. This report does not constitute a standard, specification, or regulation.
3

This page intentionally left blank. 4

1.Report No.: FHWA-GA-14-1226

2. Government Accession No.: 3. Recipient's Catalog No.:

4. Title and Subtitle:
Information Services in Social Networked Transportation: Governance and ITS

5. Report Date: June 2014
6. Performing Organization Code

7. Author(s):
Dr. Hans Klein (P.I), Dr. Kari E. Watkins, PE (P.I.), James Wong, Landon Reed, Victor Wanningen, Bingling Zhang

8. Performing Organ. Report No.:

9. Performing Organization Name and Address: Georgia Institute of Technology School of Civil and Environmental Engineering School of Public Policy
12. Sponsoring Agency Name and Address: Georgia Department of Transportation Office of Materials & Research 15 Kennedy Drive Forest Park, GA 30297-2534

10. Work Unit No. 11. Contract or Grant No.:
GDOT Research Project No. 0010766 (RP 12-26; UTC Sub-Project) 13. Type of Report and Period Covered:
Final; May 2012-June 2014
14. Sponsoring Agency Code:

15. Supplementary Notes: Prepared in cooperation with the U.S. Department of Transportation, Federal Highway Administration. 16. Abstract:
The purpose of this research seeks to understand the functions and the benefits of social networked transportation (SNT), the processes that make SNT possible, and the institutional innovations needed to facilitate those processes. First, this research examines the design of procedures for standards-setting, using real-time transit data standards from both public and private organizations as a set of case studies. Secondly, this research has identified and analyzed an emerging data network in transportation, traffic management centers and third-party data providers via a web-based survey of TMC managers. Thirdly, this research pursues understanding foundational principles of and strategies for social networking, taking lessons from successful social networks in the IT sector (i.e. the Internet), and lessons from emergent social networks in other sectors (i.e. energy). Finally, a graduate level course and an application developer conference called Transportation Camp South are discussed as methods to move into the future. It is expected that the results of this research will interest a wide audience, from transportation researchers to field practitioners.

17. Key Words: Probe-based data; third-party data; traffic management centers; highways; transit; standard setting

19. Security Classification (of this report):
Unclassified

20. Security Classification (of this page):
Unclassified

Form DOT 1700.7 (8-69)

18. Distribution Statement:

21. Number of Pages:
209

22. Price:

5

This page intentionally left blank. 6

TABLE OF CONTENTS
Executive Summary ...............................................................................................11 Chapter 1: Background..........................................................................................15 Chapter 2: Course on Social Networked Transportation ........................................18 Chapter 3: Transit Information Standard Development ..........................................20
Introduction ......................................................................................................... 20 Scope .............................................................................................................. 23
Background ........................................................................................................26 Real-time Transit Information ..........................................................................26 The Need for ITS Data Standards ...................................................................30
Literature Review................................................................................................37 Standards Development Theory......................................................................37
Real-Time Transit Standards Development ........................................................60 Methodology ...................................................................................................60 Case Studies...................................................................................................63 Comparison of Standards and Standards Development Processes.................83
Recommendations .............................................................................................. 87 Moving Ahead for Innovation in the 21st Century .............................................87 Predictions for Continued Trends ....................................................................88 Federal Policy Recommendations ...................................................................90
Conclusions ........................................................................................................92 Key Findings ...................................................................................................93 Future Work ....................................................................................................94
Chapter 4: Traffic Management Centers and Third-Party Data ..............................97 Literature Review................................................................................................97 Traffic Engineering ..........................................................................................97 Traffic Management Centers .........................................................................100 Changes in Traffic Sensing Technology ........................................................ 104 Networked Government ................................................................................105 Public Private Partnerships ........................................................................... 106 Risk Assessment...........................................................................................107 Methodology ..................................................................................................... 107 Survey Results and Analysis.............................................................................109 Existing Risk ................................................................................................. 111
7

Real-Time Third-Party Data........................................................................... 113 Hypothetical Use ........................................................................................... 114 Discussion and Conclusions ............................................................................. 119 Chapter 5: Intelligent Systems in the Transportation and Energy Sectors ........... 121 Introduction ....................................................................................................... 121 Conceptual Frame of Reference ....................................................................... 123 Governance Framework ................................................................................ 123 Layered Model of Internet Connectivity ......................................................... 124 Conceptual Heuristic for the Comparative Analysis .......................................128 Results: Comparative Analysis ......................................................................... 129 Characteristics of Operational Domain .......................................................... 129 Institutions and Prescriptions......................................................................... 133 Network Applications Areas .......................................................................... 135 Conclusions ...................................................................................................... 142 Link Layer: Need for Wireless .......................................................................142 Latency ......................................................................................................... 143 Uncertainty, Information, and Value ..............................................................144 Locus of Innovation ....................................................................................... 145 Governance .................................................................................................. 146 Chapter 6: Conclusions and Recommendations for Further Research ................ 147 References ........................................................................................................... 150 Appendix A: Materials from Course on Social Networked Transportation ............ A-1 Appendix B: Additional Questions and Responses from TMC Survey ................. B-1
8

LIST OF TABLES
Table 1: Agency responses to question on underutilized AVL functions ......................28 Table 2 Comparison of key program interests for ITS in 2000 and 2013 .......................31 Table 3: Importance of open standards requirements to different stakeholders ............57 Table 4: Openness index scores for real-time transit passenger information ................84 Table 5: Average adoption rate for real-time standards ...............................................87
9

LIST OF FIGURES
Figure 1: Growth of transit agencies with open data by passenger miles served ...........21 Figure 2 Diversity of technology and equipment vendors for AVL systems....................30 Figure 3 Growth of open source lines of code from 1995 to 2006..................................59 Figure 4: Adoption of GTFS by U.S. transit agencies. ...................................................65 Figure 5: Number of documented changes for GTFS vs. GTFS-realtime.......................69 Figure 6: Diagram of TCIP Model Architecture ..............................................................73 Figure 7: Diagram of conceptual hierarchy for TCIP building blocks..............................74 Figure 8: Participants by sector in TCIP Passenger Information Technical Working
Group ...........................................................................................................75 Figure 9: Adoption of real-time data standards ..............................................................86 Figure 10: Reasons given by transit agencies for not providing public arrival times.......90 Figure 11: Issues agencies have with adoption of open standards for real-time data ...95 Figure 12: Relationships among traffic speed, flow, and density ..................................98 Figure 14: Primary and secondary functions of traffic management centers ...............110 Figure 15: Types of end point equipment used for traffic monitoring...........................111 Figure 16: Risks and potential impacts on the traffic management system .................113 Figure 17: Reasons traffic management centers choose not to use third-party data...115 Figure 18: Information traffic management centers' would consider purchasing from a
third-party vendor ........................................................................................ 116 Figure 19: TMC required understanding and transparency of third-party data ............ 118
10

Executive Summary
Over the past twenty years, the transportation sector has experienced an information technology (IT) revolution as the national program in Intelligent Transportation Systems (ITS) planned and launched a wide variety of IT-based systems. Today, the transportation sector is poised for a second IT-driven revolution even more far-reaching than the first.
In this project, we will call the second IT revolution "social networked transportation" (SNT). SNT realizes the functionality of social networks, already well known in the IT sector, in the transportation sector as well. Social networked transportation leverages pre-existing IT investments to realize new services and functions that significantly enhance mobility. Based on the experiences of other sectors in the economy where social networking is well underway, social networked transportation is predicted to require less investment than even traditional ITS as it can generate similarly enormous benefits.
This research combines research in social networking and research in transportation to achieve useful insights into social networked transportation (SNT). This project will analyze information flows and institutions in surface transportation in order to promote new information services. It attempts to illuminate the evolving role of state DOTs as transportation becomes more information intensive.
Traditionally, transportation is understood as the physical displacement of people, goods, and vehicles. Information technology is often used to model the system or to optimize the system. However, now, information is the essence of the system. In the social networked paradigm, transportation is reconceptualized as an information ecosystem in an institutional landscape.
Transportation consists of information services, i.e. data that are generated, exchanged, combined, processed, packaged, and distributed among institutions in
11

government, industry and the consumer market to perform a variety of functions. Information services provide both qualitative improvements to transportation (new services) and quantitative improvements (better performance of traditional transportation functions).
This research seeks to understand the functions and the benefits of SNT, the processes that make SNT possible, and the institutional innovations needed to facilitate those processes. The research focus is three-fold. First, it examines the design of procedures for standards-setting. As the transportation sector fully integrates with information technology, transit agencies face decisions that expose them to new technologies, relationships, and risks. With the rise in transit-related web and mobile applications, a set of competing real-time transit data standards from both public and private organizations have emerged. Case studies and interviews were conducted with members of standard-setting organizations of the three real-time transit data standards: the General Transit Feed Specification Realtime (GTFS-realtime), the Service Interface for Real Time Information (SIRI), and Transit Communications Interface Profiles (TCIP). This analysis produced an assessment of federal policy on standards development as well as current and future trends in this sector both technical and institutional. The results will inform federal transit policy and future action in standards-setting and intelligent transportation systems (ITS) requirements, identifying the potential catalysts that will increase the effectiveness of federal and agency-level programs.
Secondly, the research identifies and analyzes emerging data networks in transportation, focusing on traffic management centers and their attitudes towards thirdparty data. Existing traffic monitoring systems in the United States are largely infrastructure-based networks with end-point devices to report spot traffic speed, density, and counts to centralized traffic management centers (TMCs). Emerging probe technologies, such as GPS-enabled devices, offer new traffic monitoring methods for
12

TMCs. These technologies involve a fundamental change in TMCs' organizational structure; however, public agencies are unlikely to have the in-house expertise to deploy and manage large-scale mobile data aggregation. In these situations, agencies will likely require participation by third-parties as technology partners. The objective of this research is to assess the readiness of TMCs and their managing agencies to adopt third-party, probe-based data for traffic monitoring and the associated organizational changes. This research does not explore the technological options for probe-based data, but rather assumes the existence of a third-party data product that can provide real-time speed data for roadway segments based on mobile device data. The major findings from the web-based survey of TMC managers are that agencies are already exposed to third-party risks; that the industry is likely to have a large transition period in which agencies build confidence in the adequacy and permanence of the third-party data; and that third-parties will need to increase transparency and openness around the technology to build trust amongst agencies.
Thirdly, this research pursues understanding foundational principles of and strategies for social networking, taking lessons from successful social networks in the IT sector (i.e. the Internet), and lessons from emergent social networks in other sectors (i.e. energy). A comparative analysis was done identifying the similarities and differences between the application of the Internet to the transportation sector (intelligent transportation systems) and the energy sector (smart grid systems). A conceptual framework was developed to compare the two sectors. Researchers conclude that the transportation sector may present greater challenges to network adoption and may also be more radically transformed by networks. Where the Internet is appropriate, the costly uncertainty that characterizes the transportation sector means that innovation could happen rapidly. However, where its latency characteristics render the Internet inappropriate, it remains to be seen whether the transportation sector can successfully
13

develop totally new protocols and media. As new players enter the transportation sector, effect control of operations could be affected.
Ultimately, the research discusses lessons for the future and offers strategic directions and promising approaches. A graduate level course was developed to teach students about the ITS system and its relationship with the Internet. Additionally, funding from this project was used to host the second annual Transportation Camp South where transportation professionals discussed the future of the industry. It is expected that the results of this research will interest a wide audience, from transportation researchers to field practitioners.
14

Chapter 1: Background
Social networks join previously autonomous people and devices into connected networks that enable previously scattered data and intelligence to unite in an information ecosystem rich with functionality. Understanding how social networks work and are achieved can create systems of great value.
Social networking has already taken off in the IT sector. The Internet is the most notable example. The Internet is merely a software protocol that runs on top of a preexisting infrastructure of computers and data networks. As it developed, the Internet required minimal investment in new hardware, networks, or skills, yet it unleashed staggeringly large amounts of additional value from those assets. Other social networks have unleashed comparable gains. Google's search engine, for example, connects users with pre-existing content and thereby creates vast value. Likewise, Craigslist.com facilitates transactions between pre-existing sellers and buyers, and in so doing has fundamentally changed consumer markets.
Realizing the benefits of social networks and social networked transportation requires understanding as to how they are created. Perhaps the most important insight here is that the creation of social networks involves at least as much institutional innovation as technological innovation. For most such networks, the underlying infrastructure already exists, but its utility can only be unleashed through social processes that are institutional in nature.
Three essential elements of social networks were identified and traced back to institutional innovation. The three core elements of social networks are technical standard-setting, network interconnection and application development.
Technical standards are data formats and communication protocols. A community that develops such standards creates the preconditions for wide communication. Standardized data mean that the content of communication can be understood by
15

everyone in the community, and standardized protocols mean that the content can be assessed throughout the community. An information-rich environment is possible when data can be widely shared and understood.
The main challenge to standardization is institutional in nature, not technical. It is difficult for a community to achieve widespread agreement among its numerous members. Often technical standards are only achieved after the creation of appropriate institutions, institutions that make collective dialogue and agreement possible. Understanding technical standard-setting processes and the institutions that embody them is crucial for creating social networks.
The second core element in social networking is network interconnection. Standards make it possible to connect, but ultimately members of the community have to decide to seize the opportunity to connect. As with technical standard-setting, the challenge to interconnecting is institutional, not technical.
The decision to interconnect is made in the context of organizational policies, plans, and agreements. Interconnection may be impossible without changes to attitudes, rules, and even property rights. Again, institutional innovation is required. Understanding interconnection decisions requires awareness of historical, cultural, and organizational factors, factors which are often summed up as "That is just the way we do things around here." Practical insights into interconnection involve the study of incentives, organizational change strategies, and cost and benefit calculations.
The third core element in social networking is application development. Once data are standardized and interconnected, it still remains to develop applications to convert that data into useful information. Application development is more of a technological task, but often the core of the technology is institutional in nature. Good applications route around institutional barriers, unite collaborators, and create incentives to participation. Systems designed for one context are likely to yield insights for developers
16

working in other contexts. It seems likely that transportation could learn from other sectors, such as the energy sector where smart grids are being realized through the application of social networking strategies.
The importance of institutions in social networks can be summed up in one word: governance. Social networks emerge where governance institutions emerge that allow for collective decisions on standards, interconnection, and application development. The benefits of social networking have been demonstrated in the IT sector. Researchers are only now beginning to understand the dynamics of their creation and the strategies for achieving them. The application of these insights to surface transportation remains to be done, as does the development of practical strategies for achieving social networked transportation.
This report proceeds as follows. Chapter 2 discusses a course developed in Social Networked Transportation which focused on the topic of transportation and the Internet. Chapter 3 focuses on the development of technical standards in transit information and communication by institutions. Chapter 4 discusses the readiness of traffic management centers to use third-party data, which would require the cooperation of the public and private sectors and a restructuring of the institutions. Chapter 5 focuses on the lessons in social networking that the transportation sector can learn from the energy sector. Finally, Chapter 6 discusses the future trends, visions, and goals for the transportation sector.
17

Chapter 2: Course on Social Networked Transportation
Information technology is revolutionizing transportation. In the public sector, the United States program in intelligent transportation systems (ITS) has developed and deployed specialized systems for transportation. In the private sector (and increasingly in the public sector), new products and services are being offered on the Internet. The Georgia Institute of Technology offered a graduate-level course in the fall 2013 semester on ITS and the Internet. This course was taught by Dr. Kari Watkins from the Civil and Environmental Engineering Department and Dr. Hans Klein from the Public Policy Department. The course examined IT technology and policy in transportation, including Internet technology and the institutions and application areas of transportation. Topics included public-private partnerships in transit, traffic management, vehicle-to-vehicle networks, standards setting, and the role of the insurance industry.
The course began with an introduction of the topic of transportation and the Internet and discussed hot topics in each field. Students contributed to brief discussion of transportation-related applications or websites, facilitated by Dr. Watkins and Dr. Klein, where they presented on how the application worked on the simplest level, the back-end data required for the application to work, the user interface, and the broader implications of the application. The faculty then discussed the legal framework of transportation planning so students could understand the background and current institutions involved in transportation. The students also read articles regarding Web 2.0 and Google Fiber.
The course then moved to a discussion of Intelligent Transportation Systems (ITS). It began with a background of the ITS program in the US. Students were assigned sections of the current focus of the ITS program to research and make short presentations in class. The faculty led a discussion regarding the future of ITS, connected and autonomous vehicles, and the liability associated. Students learned about dedicated short range communication for the USDOT connected vehicles
18

program. Students wrote one of two term papers about the layered model of communications and applied this model to vehicle-to-vehicle communications; this paper was written in TRB format.
The course also had several guest speakers. Landon Reed presented on transit standards and standard development, mainly GTFS, SIRI, and TCIP. James Wong presented on networked government as it relates to traffic management centers and third-party data. Victor Wanningen presented a comparative analysis of the energy sector and the transportation sector in terms of intelligent systems.
Finally, the course discussed the Internet as a platform for data exchange, focusing specifically on open data and transportation applications. Students learned about social media applications to ITS and crowdsourcing as well as utilizing smart phones as invehicle platforms. Students wrote the second of the two term papers on a comparison of a public sector application to its private sector counterpart, also in TRB format. Students made lectern style presentations to the class to end the semester.
Overall, the course was highly rated by students, who came from various backgrounds, such as Civil Engineering, City Planning, and Public Policy. The course was taught in a seminar style and the faculty members were engaging and helped promote healthy discussion. The syllabus and other related course material is available in Appendix A. Original versions of these materials are available for use by academics and practitioners by contacting Dr. Watkins or Dr. Klein.
19

Chapter 3: Transit Information Standard Development
(Landon Reed and Dr. Kari Watkins)
Introduction
Passenger information for public transit, particularly in the form of real-time arrival predictions, has experienced a surge of growth in the past decade. While the first passenger information systems existed even in the early 1990s (1), the increasing diffusion of mobile smart devices has enabled new generations of applications that allow users to access real-time information with increasing ease and reliability. The benefits of providing this information, especially via mobile applications, are well documented. Such benefits include significant reductions in perceived and actual wait times (2), improvements in customer satisfaction (3), and increases in transit usage (4).
Smartphone market penetration, however, does not fully account for this growth in real-time information delivery. The market success of the standard format for schedule data known as the General Transit Feed Specification (GTFS), originally developed through a partnership between Google and Portland's TriMet, has led to an unprecedented adoption rate by transit agencies as shown by total unlinked passenger trips for agencies with GTFS in Figure 1. These agencies have committed to producing and maintaining their schedule data in standardized comma separated values (CSV) tables to display their system on Google Transit's trip planner and, increasingly, opening this data to other third-party application developers.
20

Figure 1: Growth of transit agencies with open data by passenger miles served (49)
While GTFS has emerged as a de facto industry standard1 for static schedule
information, there has yet to be a similar case for real-time passenger information, or the
current location of a transit vehicle and its consequent schedule deviance. Although the
menu of real-time data standards is almost identical in composition to the list of options
available for schedule data standards, a predominant alternative has not yet risen to the
1 Some may call attention to the difference between the use of the word "standard" to describe what actually is a specification (for a good description of this difference, albeit in the printing and publishing industry, see http://www.npes.org/pdf/Standards-V-Specs.pdf). While this is a valid semantic concern, the difference between standard and specification lies on a continuum. Specifications that have been widely adopted and are openly maintained begin to move into the realm of standards. For this reason, the words may be interchanged throughout this document. This is not to detract from the respectable and painstaking work of accredited standards bodies, but rather just a side effect of the ever-changing landscape of adoption and usage of standards and specifications.
21

top. This may be due in part to one or more of the following reasons: (1) the market for real-time information is not mature enough to warrant widespread adoption, (2) the available data standards do not meet the technical needs of agencies, or (3) the effects of lock-in and switching costs keep agencies fixed in contracts with vendors providing proprietary solutions.
Nonetheless, the market for standards that do exist for real-time transit passenger information in the United States is at a stage where the tipping point for adoption seems likely to occur over the next decade. The open standards for delivering real-time passenger information are (1) the General Transit Feed Specification for realtime (GTFS-realtime), the real-time counterpart of GTFS; (2) Transit Communication Interface Profiles (TCIP), the Federal Transit Administration (FTA) and the American Public Transportation Association's (APTA) decades-old project that includes specifications for all manner of technology systems in the transit industry; and (3) the Service Interface for Real-time Information (SIRI), a passenger information standard developed by the European Committee for Standardization (CEN), which has seen adoption in whole or part by a few agencies in the US. There are a bevy of other standards for delivering real-time information, but these are on the whole closed standards--generally controlled by proprietary interests without open forums for comments or appeals. Examples of other standards or specifications include the NextBus XML application programming interface (API), web services provided by many different automatic vehicle location (AVL) or ITS vendors (Trapeze, Clever Devices, Orbital, etc.), the OneBusAway API2, and many custom implementations (such as TriMet's web services API).
2 The OneBusAway API is not fully closed; but for the purposes of this research, it is not considered here. The primary reason for its exclusion is that most of the discussion and work surrounding the API has been related to a particular implementation of the standard. As the project grows into other regions (New York City, Tampa, Atlanta, etc.), there may be a cause to consider it under future research. Another reason for its exclusion here is that the author contributes directly to The OneBusAway Project and wishes to avoid conflicts of interest.
22

There are likely a number of reasons that exist for why a real-time transit passenger information standard has not yet reached a tipping point. This research aims to understand the theory on standards development processes and organizations in an attempt to better understand standards development for real-time transit passenger information and why widespread standardization has not occurred. It will examine other cases of competing standards and how these processes were structured. Importantly, it will reflect on standards theory and the role of policy in promoting successful standards.
Scope The literature review and case studies that follow in chapters three and four
represent an analysis of standards development with a particular and well-defined scope. The analysis will focus strictly on those standards development processes for real-time passenger information in the United States.
Real-time Passenger Information Transit Data Standards The scope of this work is limited in order to produce results that are relevant for a
particular subset of industry data standards and those organizations that develop those standards. The standards under examination in this research are those that convey passenger information in a real-time context. Such information includes data reported about transit vehicles pertinent to the vehicle locations, schedule adherence/deviance, service disruptions or changes, or even network congestion levels. These data may be used to convey information about transit service that aids travelers in decision making about their journeys.
It is worth noting that certain standards considered here, especially TCIP, contain standards for an entirely other set of information exchanges for the transit industry. GTFS-realtime, on the other hand, was designed and designated strictly for the
23

conveyance of real-time passenger information. As such, a strict "apples to apples" review is not possible unless only the real-time passenger information components of TCIP are considered. While the author recognizes that the real-time component of the standard does not exist in isolation, for the sake of simplicity, it will be compared strictly in this real-time passenger information context.
Another important consideration is that TCIP and SIRI were both developed for intra-agency interoperability, whereas GTFS-realtime was developed as a model for external data consumption by third parties. Although on the surface these models exhibit fundamental differences, the primary goal here is to consider how standards influence the ability of transit passengers to consume real-time information. The passenger information components of TCIP, SIRI, and GTFS-realtime all intend to serve this purpose, whether the ultimate vehicle be an agency-operated website or variable message signs, Google Transit, or any number of other web or mobile interfaces. Each of these data standards have the capability to deliver this information; this research will consider how the development of the data standard has hindered or helped to this end.
Process-oriented Analysis This research effort seeks to understand the evolution, history, and future of the
standards development processes of the major real-time passenger information data standards in the United States. By understanding these processes as well as the economic, political, and technical dimensions of these standards, the purpose of this work is to recommend a path forward for the industry in standards adoption and future standards development work, especially as it pertains to real-time passenger information. Rather than a substantive analysis of the content, format, and structure of the data standards, this research effort seeks to understand the formal approaches
24

taken by standards development organizations (SDOs) and the approaches' resultant successes and failures.
United States Focus While advanced traveller information systems (ATIS) have been deployed for both
transit and traffic systems across the world, this research focuses strictly on the United States context. Social and political organization varies country to country as do the makeup of SDOs and their relationship with governmental entities. Because of the complexity of such relationships in different contexts, this research will only consider real-time passenger information standards that have been implemented and used in the United States, particularly for those agencies that are members of the American Public Transit Association (APTA).
SIRI, which was developed through CEN, represents the convergence of a few European real-time information standards, most notably the UK's Real-Time Interest Group (RTIG) and Germany's Verband Deutscher Verkehrsunternehmen (VDV). It also draws on the basic conceptual framework put forth by France's TransModel, also a CEN European Standard. While the SIRI data standard was developed through a European SDO with solely European partners, a number of US agencies and real-time information vendors have implemented the standard, bringing it into the pool of other US data standards and into this analysis.
Open Standards As mentioned above, this research will consider only open standards for real-time transit passenger information. Any recommendations for policy or process are unlikely to impact a closed standard. Therefore, in order to pursue productive work, closed and proprietary specifications are wholly excluded from the case studies and consideration
25

as a possible filler for the real-time transit passenger information standards void. The permanence of proprietary specifications relies on the perpetuity of the firm that holds licensing, intellectual property rights, and general control of the standard. As such, a realistic, long-term solution will not include closed or proprietary specifications. Chapter three considers further the subtleties of open standards and will aid the reader in the understanding of this concept.
Background
The purpose and utility of real-time transit information has changed over time. Transit agencies originally installed systems that provided information on vehicle location for operational reasons--to assist with crucial functions such as dispatching. Today, these systems integrate with other technology subsystems such as automatic passenger counters (APCs), influencing the way in which an agency assesses its operations and even communicates with its customers, improving both the quality of service and the customer experience. This section will explore both the technical and historical basis of the technologies that provide this information and how some of these changes have occurred.
Real-time Transit Information Real-time transit information provides agencies, operators, and customers with
information about the current transit operations--whether it be a single transit vehicle, a route, or an entire fleet.
Automatic vehicle location (AVL) refers to, primarily bus, technology systems that determine the location of a transit vehicle or fleet of vehicles in operation. According to TCRP Synthesis 73, an AVL system is defined as:
26

"the central software used by dispatchers for operations management that periodically receives real-time updates on fleet vehicle locations. In most modern AVL systems, this involves an onboard computer with an integrated Global Positioning System receiver and mobile data communications capability" (5).
One of the primary technologies for early AVL systems installed in the 1970s and 1980s was the wayside signpost beacon system, which relies on a set of signposts installed at key locations on the transit system (sometimes coinciding with features of service like timepoints) and beacons that emit, usually, microwaves to indicate their presence when they approach a signpost. This technology, still used for transit signal priority, is increasingly being replaced by GPS-based systems, wherein each transit vehicle is equipped with a GPS receiver and radio-based mobile communications system.
Transit agencies rely on real-time transit information for a host of operational capabilities and improvements, beyond the information provided specifically for passengers. Updates on the location and status of vehicles can be integrated with a menu of other on- and off-board technology subsystems to provide functionalities such as onboard next stop announcements, automatic data input for headsigns, advanced communication with farebox systems to provide enhanced data on payments, stop-bystop boardings and alightings, schedule adherence for real-time predictions when linked with schedule data (provided through a number of different interfaces), improved transit signal priority (TSP) operation, and more (5). This abbreviated list provides a snapshot of the usefulness of real-time information updates on the location and status of transit vehicles in operation.
Though the menu of options for AVL systems is extensive, the reality of many implementations is that few transit agencies utilize many or all of these capabilities. In a survey conducted by Miller, et al., for TCRP Synthesis 73 (5), the researchers asked
27

transit agencies which aspects of the agency's bus AVL system are not fully utilized. The responses for this question are shown in Table 1. While the highest percentage of agencies had not fully utilized TSP (at 43.8%), the second highest response was Next Arrival Predictions at 34.4% of transit agencies (5). Over a third of agencies either are not providing or have not fully utilized arrival predictions for their transit systems. The low utilization of TSP can partly be explained by the high capital costs of installing wayside infrastructure and the coordination costs of working with other agencies to calibrate and manage traffic signals. Yet the low utilization of Next Arrival Predictions is not as easily explained by infrastructure costs.

Table 1: Agency responses to question on underutilized AVL functions (5)

Technology

%

Transit Signal Priority (TSP)

43.8

Next Arrival Predictions

34.4

Scheduling and Dispatch Software for Paratransit

31.3

Operations

Automatic Passenger Counters (APC)

28.1

Next Stop Announcements

21.9

AVL Software for Fixed-Route Operations

18.8

Other

0.0

While arrival predictions can be delivered with costly wayside digital signage, information delivery via websites, automated telephone systems, or mobile applications offers a low-cost alternative to this infrastructure. One possible explanation for this high response is that when the researchers administered the survey in 2008, these low-cost technologies were less available. This theory can be discredited by survey responses indicating that the earliest cases of agencies delivering next arrival predictions by signs or websites were between 1998-2000 at rates of 9.4% and 3.1%, respectively. Indeed, these low-cost methods were available, but this researcher posits that sufficient
28

dominance of a standard in the realm of real-time transit passenger information had not, and perhaps has still not, matured enough to make these low-cost alternatives to wayside signage economically viable. In the absence of reliable standards, market inefficiencies keep the costs of Next Arrival Predictions too high.
Beyond the underlying technologies and uses, the number of vendors involved in installing and developing these systems for agencies adds an entirely separate layer of complexity. Figure 2 shows the various vendors involved in equipment supply or technology integration mentioned in responses from 31 agencies to a 2008 survey question conducted for TCRP Synthesis 73 (5). The wide distribution of responses (note: these responses were not mutually exclusive, i.e., some agencies mentioned multiple vendors/suppliers) suggest that there are a number of both large vendors with multiple contracts across different agencies as well as many cases where smaller vendors may create custom solutions for individual agencies or, at most, small market segments. There are many technology providers for AVL systems and, based on recent evidence, few of these vendors use anything besides proprietary, closed standards for disseminating real-time passenger information within agencies or to third parties.
29

Number of agencies with vendor

25 20 15 10
5 0
AVL component vendors
Figure 2 Diversity of technology and equipment vendors for AVL systems (5)
The Need for ITS Data Standards ITS Architecture / Standards: Final Rule
Intelligent transportation systems (ITS) became a part of the federal agenda in the early 1990s with the passing of the Intermodal Surface Transportation Efficiency Act (ISTEA) of 1991. ITS represent the efforts to integrate information technology into transportation infrastructure at any number of entry points, for example, private vehicles or public infrastructure like roadways. Table 2 shows the key activities of the ITS Joint Program Office of the USDOT in 2000 (6) and in 2013 (7).
30

Table 2 Comparison of key program interests for ITS in 2000 and 2013 (6, 7)

Date accessed

January 16, 2000

September 3, 2013

Question Answer (extract)

What are the key elements of the ITS metropolitan approach?
Traffic signal control

Freeway management

Transit management

Incident management Electronic toll collection Electronic fare payment

Railroad crossings Emergency response Regional multi-modal traveler information --

What are the current key activities of the Federal ITS Program?
Vehicle to Vehicle (V2V) Communications for Safety Vehicle to Infrastructure (V2I) Communications for Safety Real-Time Data Capture and Management Dynamic Mobility Applications Road Weather Management Applications for the Environment Human Factors Mode-Specific Research Exploratory Research
Cross-Cutting Activities

A comparison of the major activities across the years indicates not necessarily a distinct shift in priorities, but rather a shift in the way the organization addresses these priorities towards more complex and interactive systems. However, the disappearance of any explicit reference to "transit" may indicate a shift in priority to traffic and autos, especially with the ever growing interest in vehicle-to-vehicle (V2V) communications and unmanned autonomous vehicles (UAVs). Nevertheless, this may just as well be explained by the contemporary emphasis on multimodal applications rather than treating modes as discrete, unrelated subjects.
In the Transportation Equity Act for the 21st Century, enacted in 1998, legislators filed additional rules for ITS projects that were to be funded by the Highway Trust Fund. These rules specified that any major ITS project must "...conform to the national
31

architecture, applicable standards or provisional standards..." (8). This provision extends to any ITS projects funded out of the Mass Transit Account and, therefore, includes most projects that may impact the regional coordination of local ITS operations. It should be clarified that conformance to the "national architecture" in practice requires conformance to a regional ITS architecture, which is based on the National ITS Architecture, a much more expansive system than any region is ever likely to implement (9).
In response to questions posed during the legislation's comment period, the Federal Transit Administration (FTA) modified the final policy to alleviate concerns regarding "the premature use of required standards and interoperability tests..." Specifically, the FTA relinquished agencies of the need to use any standard that is not yet "mature" and has not been formally adopted by the USDOT. At the time of the modification's writing, the only required standards were those related to commercial vehicle operations (CVO) (10). According to a report published in 2010, no other ITS standard has yet to be formally adopted by the USDOT, so it holds that agencies are not formally required to utilize any standard. Nevertheless, the report notes that policy still encourages the use of those standards developed by recognized standards development organizations (SDOs), such as the American Public Transit Association (APTA) (11).
Branscomb and Keller (1996) offer an early summary of the challenges facing ITS standardization and, perhaps, partial explanation for why no standard has been formally adopted by the USDOT. In Converging Infrastructures: Intelligent Transportation and the National Information Infrastructure, they write:
"ITS standardization issues are complex relative to those in the traditional telecommunications environment because they span a broader array of technologies and systems. At the same time, however, the environment for standardization is
32

relatively weak. Telecom standards evolved with a common platform and a stable-- indeed regulated--competitive environment; ITS will consist of heterogeneous systems and a relatively independent set of players. In addition, many of the technologies for which standards will be most needed are nascent or immature at this time" (12).
Many of the same challenges exist nearly two decades later. Technologies and systems remain diverse and complex. Most of the policy efforts tied to standardization have been limited to light incentives, certainly not mandates. And, barring a few examples, standards in the transit industry still seem nascent and/or immature, a fact which is supported by the above mention of USDOT's hesitancy to formally adopt any ITS standard.
Despite this apparent stagnancy, a couple of things have changed dramatically. First, web and mobile platforms for personal information delivery have exploded, despite the survey responses from TCRP Synthesis 73. The personal computer and, more recently, the smartphone have enabled transit agencies--and anyone with an Internet connection--to communicate efficiently with larger and larger audiences. A separate, yet certainly related, occurrence is the emergence of the open data movement. The democratization of information and datasets have created an ever-broadening market of users and implementers who inject a distinct set of values, such as transparency, openness, and sharing, into these standardization processes. In order for standards to succeed in this new marketplace, the bodies that maintain these standards may need to demonstrate a renewed commitment to these ideals--both that the standard is developed/maintained and how new stakeholders might interact with the standard.
Open Data and Standardization
Executive Order (EO) 13642 issued by President Obama on May 9, 2013, has broad-reaching impacts for open data and data standards in the United States (13).
33

Proponents of open data, discussed in more depth in Chapter 4, affirm that government should provide its data freely and openly to private citizens and corporations in order to spark innovation and assist government in performing its various functions. Using its oftcited poster children of weather data and the Global Positioning System (GPS), the EO discusses the immense potential for entrepreneurial activity and economic growth when public data are made freely available. Importantly, it asserts that "the default state of new and modernized Government information resources shall be open and machine readable [emphasis added]" (13). By providing government data in machine-readable formats by default, the federal government is placing a new level of importance on the role of standardization in the most basic operations of government. Standardization, if not a prerequisite for the systematic provision of machine-readable data, is at the very least a logical conclusion for the effort.
This EO and the policy it represents are important for the future of transit data standards because it cements the pattern of growth and creation of niche data markets in sectors such as transportation, health, or education. With this growth comes the continued importance of data standards to convey this information in addition to the processes by which such standards are developed. While standardization efforts in ITS are over a decade old, the executive branch's relatively new open data policy allows an opportunity to revisit these efforts and investigate how this "open paradigm" might impact preexisting policy and methods. Certainly, most of the ITS standards have been developed to be open standards; however, properly functioning in support of open data poses new questions for these transit standards, particularly in how to handle an entirely new set of stakeholders.
34

Pluralization of Stakeholders
Just as the release of Global Positioning System (GPS) spurred billions of dollars in innovation and supported the spread of businesses around the globe, the opening of historically closed or unavailable datasets is spawning a new set of interests and stakeholders in transportation data from governments. According to a report released in October 2013, open data have the potential to unlock billions, even trillions, of dollars in economic value in the US. For the transportation sector alone, there is around $720 to $920 billion in latent value, suggesting that new stakeholders might be very important for the overall economy (14). These new interests not only have a stake in if/when an agency releases data, but also in how these data are provided once it is eventually delivered.
This new generation of stakeholders historically has had little influence on the development of ITS standards. This of course is a natural consequence of arriving late to the game, yet this is not to say that such parties have not been addressed. In a 2012 roundtable held by the White House Office of Science and Technology Policy (OSTP), application developers and other transit industry stakeholders met to address challenges facing the transit industry, namely "(1) a lack of consensus on standards for the exchange of real-time transit data and (2) a lack of 'clinical trials' of cutting-edge technologies in this area" (15). The direct outcomes of this meeting are not abundantly clear. In fact, that the meeting even took place at all is difficult to ascertain because it is only published on a few blogs. Nonetheless, the convening of such a meeting shows that the federal government is aware of the issues in adoption of current standards and bringing transit technology forward. As more and more agencies move towards an open data model, this pluralization of stakeholders opens up opportunities for transformative change in the public transit industry.
35

Efficient Competition and Innovation
The most fundamental motivation for pursuing transit ITS or any other set of data standards is to enable efficient competition and innovation. The economic arguments for standardization espouse the positive welfare benefits that widely adopted standards generate and, conversely, the failure of technologies and innovations to which incompatible standards can lead (16). Such positive benefits include network effects, the avoidance of lock-in, reduction in switching costs, and enabling new market entrants, all of which will be explored further in later chapters (1719). Put simply, standards lead to a more efficient arrangement of market forces and competition. While the success of standards may not be in the interest of existing firms within the industry, it is certainly in the interest of the general welfare of the public, who perceives such activity in the form of cost reductions and improvements in services.
In considering the value of standards to transit ITS, it is helpful to consider the genesis of GPS technology. Surely, if the federal government had delegated the management of GPS to local authorities, we would see the geographies of various jurisdictions encoded differently to serve different needs. A state government may choose to represent each point of latitude and longitude in reference to a coordinate system that distorts the state's geography the least. Or a local municipality may choose to represent every point in reference to the city center, a logical decision. Or an extremely flat county might choose not to represent altitude in its local GPS at all. In reality, we see different coordinate systems in use in nearly every jurisdiction around the country that hosts geographic data. But if the federal government had disjointed GPS--the foundational technology for pinpointing any user's precise location at any given moment--in this hypothetical way, there would be little chance of the technology having the lasting impact on the world that it has. This illustration is of course flawed
36

(the technology is for global positioning, not local positioning), yet in an age where technologies can transform the world in mere months given the right conditions and where data have been historically locked down so tightly, the example is not altogether unbelievable.
In sum, the landscape of transit ITS standards may be in a period of change. Thanks to a growing interest in the use of government data by a new set of stakeholders and the formal recognition of these efforts by the President, there is now more than ever a need to understand the impact that standards have on the transit industry. Understanding the economic and policy impacts that standards have is a crucial first step to understanding how individual standards develop and the environments in which they are created.
Literature Review
Standards Development Theory
Standards development processes, especially in the information technology sector have received a great deal of attention in the past couple of decades. Indeed, it is the success (or failure) of such processes that have led to the fruitful (or in some cases painful) growth of industries that rely on networking and data exchange protocols, i.e., the Internet. Standards development theory draws from the fields of economics, sociology, political science, business and information technology. This interdisciplinary topic area thus has many different contributors bringing a wide range of expertise and background case studies. Nevertheless, a review of such literature reveals common threads and theoretical underpinnings.
In an attempt to cover all relevant aspects of standards development theory for realtime transit passenger information standards, this section will consider:
the economic drivers for standardization processes;
37

the institutions that have historically steered standardization processes; policymaking surrounding standardization; the types of standards and the basic function each serves; and the definition of "open standards" development (as well as differentiation between "open standards," "open data," and "open source"). This literature review provides a set of objective criteria for understanding and analyzing the real-time transit passenger information standards development. This analysis will inform the economic viability of development strategies, the appropriateness of when and where government has intervened with various policies, and the conditions of openness for each of the standards. Previous work on transit interface standards has not taken this extensive look at the theoretical literature surrounding standards development, yet in order to move the industry forward on this issue, such a review is necessary.
Economic Dimensions of Standards There are a number of economic motivations for standardization in an industry.
Each of these impart externalities onto transactions and product decisions, which spur the economic viability of products and allow technological innovation to proceed at a strong pace.
Network Effects Some of the primary economic advantages offered by standardization are derived from what are known as network effects. Katz and Shapiro (20) define network effects as "the utility that a given user derives from the good [which] depends upon the number of other users who are in the same 'network' as is he or she." Economists have
38

established a number of types of network effects3 in the past few decades, all of which contribute to an understanding of how these market externalities impact standards development and implementation.
For understanding how network effects might apply to real-time transit passenger information, consider a transit agency in isolation. The agency may have an interest in providing real-time information to customers. Developing a system to deliver this information may take significant investment in labor and/or capital to build the system from scratch. In the absence of standardization, adding additional agencies to this model does not decrease individual agency investments to provide real-time information. However, standardization drives down these costs because the costs (and benefits) of development begin to be distributed across the network. The different ways in which these effects disperse are described below.
Direct Network Effects The most basic example of network effects and one of the most modeled in the field are direct network effects. Direct network effects account for the direct increase in value accounted for by an increase in usage. Such an effect is easily explained by common communications networks, such as increases in Internet users or the number of households with a telephone. As more individuals begin using a product, the value of that product, or consumption benefit, for existing users and each additional user rises. Both Katz and Shapiro (20) and Farrell and Saloner (19) discuss these basic effects in their seminal works that were both published in 1985. Indirect Network Effects
3Arun Sundararajan maintains a thorough listing of the various types of network effects on his personal web site (http://oz.stern.nyu.edu/io/network.html) hosted at New York University from which many of the literature references were extracted.
39

Indirect network effects contribute to consumption externalities, or the how the consumption of one good may depend on the market supply/availability of other supporting or interoperable goods. Katz and Shapiro also refer to this phenomenon as the hardware-software paradigm (20), which may be recognized today in the consumption patterns of smartphones. Indeed, the availability and abundance of "apps" or native applications--or even accessories like cases or peripherals--for a particular consumer smartphone often heavily influences the purchasing decisions of consumers.
The applicability of this indirect network effect model may be limited for the transit ITS industry because of the dominance of vertically integrated vendor solutions for hardware and software. However, the model may be considered for instances where passenger information standards have been adopted by a subset of transit agencies and mobile application developers. In this circumstance, consumers have come to enjoy the benefits of software variety and freedom of choice when a transit agency chooses a standard that allows for an array of software providers to enter the market.
Two-sided Network Effects Indirect network effects are sometimes referred to as one-directional cases of
two-sided network effects. Whereas indirect network effects refer to the scenario where a variety of software packages may influence the consumption of a hardware package, two-sided network effects include this scenario along with the reciprocal, where a variety of hardware options for a given software will impart benefits on the consumption of the software. Farrell and Klemperer list "credit cards, brokers, auctions, matchmakers, conferences, journals, computer platforms, and newspapers" among key examples of two-sided network effects (21).
Local Network Effects Local network effects provide a strong theoretical understanding for standards
adoption and development in transit ITS. These effects describe the effects that a small 40

subset of a larger network has on consumption decisions. The federal requirement for developing regional ITS architectures is a policy materialization of these effects. In other words, ITS decisions made by a transit agency in a given metropolitan area will be heavily influenced by the decisions of and existing infrastructure supported by agencies within that same region. Again, this effect is supported by both the theoretical arguments made by Sundararajan (18) and the policy mandates from USDOT (10).
Lock-in and Switching Costs Besides the benefits attributed by network effects, the costs imparted on consumers where standards do not exist in a market create an important motivation for the introduction of standards. These costs, known as switching costs, may keep a consumer locked in to a particular firm (or vendor) because the cost of switching firms is too high or, put differently, "when consumers value forms of compatibility that require otherwise separate purchases to be made from the same firm" (21). When considering technology systems in the public transit sector, switching costs may derive from the use of proprietary data formats and standards. Thus, switching from one technology provider to a competitor would require high costs to translate or convert data from one system to the new. Other examples of switching costs and lock-in "include the transaction costs of closing an account with one bank and opening another with a competitor, the learning cost incurred by switching to a new make of computer after having learned to use one make, and the artificial switching costs created by frequent-flyer programs that reward customers for repeated travel on a single airline" (17). Approaches to Standards Coordination The mechanisms by which a standard develops is an important determinant for coordination, or reaching a harmonic agreement within the industry. Farrell and Saloner
41

Consider three approaches to coordination for interface or compatibility standards: committee-based, market-based (or "bandwagon"), and hybrid coordination (22).
Committee-based Coordination Committee-based coordination relies on the action of some formal body to achieve standardization across the market participants, while market-based coordination is defined by a set of competitive parties each working independently of one another (22). There are many examples of committee coordination in standardization including any standard setting organization that openly allows industry participants to meet and develop a standard through a consensus-based process (e.g., ANSI, ISO, or CEN). The hybrid approach relies on a combination of both market agents working together in a formal committee approach, while simultaneously pursuing a market strategy for a standard. Farrell and Saloner conclude that, while it may take a significantly longer time, committee-based standard setting will more likely result in interface standards coordination. Though the authors do note that as this process takes longer and longer, the marginal benefits ("payoffs") for achieving standardization through committee begin to diminish rapidly (22). Market-based or Bandwagon Coordination Farrell and Saloner suggest that standardization occurs in the market-based or bandwagon coordination environment when there is a clear leader in the market (a "first mover") that pushes the market into standardization as a side effect of its leadership. They mark key examples of this pattern as when Home Box Office (HBO) adopted VideoCipher, a satellite signal scrambling system that once adopted by the entertainment giant brought widespread coordination across the industry. Another example of this bandwagon approach is with the pre-breakup telecommunications
42

company Bell. When Bell (the firm with the largest market share by far) made decisions on products or standards, smaller companies such as GTE were forced to follow.
The Hybrid Approach The hybrid approach to standards coordination describes when a firm decides to participate actively in a committee approach while simultaneously pursuing a marketbased solution (22). This approach could be considered either hedging activity or, more aggressively, covert deception used to make a move on the market with the committee's ignorance. Keil suggests that the hybrid approach--combining market and committee elements into a semi-open alliance of organizations--a model used in the standardization of Bluetooth, is used increasingly by firms to achieve rapid dominance of new technology markets (23).
Standards Stakeholder Models
As mentioned in Chapter 2, the role of stakeholders in the development of standards is an important one, especially as this group changes with the government implementation of open data policies. This section contains a few descriptions of stakeholder models, or the types of stakeholders involved with standards development and how their respective interests play out. The section provides a context for the importance of organizations, history, and structures in standards development.
Creators, Users, and Implementers Krechmer defines a model for stakeholders in open standards development that relies on three categories: creators, implementers, and users (24). This is perhaps the most basic hierarchical division of stakeholders, yet it helps to parse out interests in the standardization process. While implementers and creators have the most stake in this process, users have important interests as well that extend beyond the technical components. West (25) presents a model with more subtleties, which provides a good
43

description of stakeholders for understanding market forces in this research. Nevertheless, both models presented here prove valuable to understanding the interaction and importance of stakeholder groups.
Creators (Standards Setting Organizations) Standards setting organizations (SSOs) is a term that has been used to characterize any organization involved in the development of standards, from governmental to nongovernmental bodies and from corporations to non-profit foundations. In a 2002 critique on the evolving nature of SSOs, Cargill defines five types of SSOs: trade associations, Standards Developing Organizations (SDOs), consortia, alliances, and the Open Source software movement (26). Cargill traces the history of SDOs, the definition typically applied for more formally organized SSOs. He uncovers the acceleration of market demand for new technology standards and simultaneous retardation of SDOs' ability to deliver standards in a timely manner. This slowing pace of development originated with the growth of "anticipatory standardization," whereby shortened product cycles and rapid technology change forced organizations to develop a standard far in advance of when it was needed by the industry (26). This change began to bring about an increasing number of consortia, or alliances of companies with similar objectives, that retracted funding from SDOs, redirecting it towards their own consortia activity. While these consortia on the whole did not participate in anticipatory standardization, the model of standardization began to change towards "existing practice." In this model, a company would submit a specification
44

already in practice to be reviewed for standardization by a consortium. The revised and reworked specification would then be submitted to the industry as a standard, though as Cargill accurately notes, "[t]he ultimate authorization, of course, was the take up of the technology by the market (26)."
The other crucial piece of this creator segment of the standardization hierarchy comes from the influence of the Open Source Software (OSS) movement. This movement, formally initiated in the late 1990s, consists of a large, semi-organized network of individuals and organizations growing increasingly diverse, but with the common goal of creating and improving bodies of universally accessible and redistributable software (27).
Members of the OSS community often extend beyond the development of software into the realm of standardization. While it may be on the other end of the continuum from large SDOs, this largely voluntary community has made significant contributions to the development of important open source software projects. The decentralized nature of many of these projects shows important similarities to the successful set of Internet open standards, which are developed in part by the Internet Engineering Task Force (IETF) (28). The model of distributed networks of volunteer technical experts has and will likely continue to have real impacts on how standards are developed. The importance of this model is further discussed later in the section on Open Standards Development.
Implementers Implementers are those players in the standardization process that create new products that directly employ the standard under development (24). This group, therefore, has a uniquely strong interest in the outcome of a standardization process. However, it is crucial to consider how these interests differ from standards creators (such as an SDO) or the user of one of the implementer's products.
45

An implementer is concerned not with whether the standard is technically sound, universally accessible, or meets some other idealistic notion of fairness, but rather that the standard is accessible to him or her and meets the needs of his or her particular products and market segments (24). This description is not to vilify implementers. Some implementers may indeed have goals that the standard conforms to firmly held values, but if the standard does not meet an implementer's needs, it is not in his or her interest to support it. It is useful here to discard the notion that firms in the marketplace enjoy competition--firms would rather the playing game be tilted in their favor, but at the very least will suffer a level playing field.
Users Users of implementations of a standard have a stake in the standard's success. Truly, when a standard reaches widespread adoption, its users gain benefits from network effects, the freedom from lock-in, and stability in their investment. Krechmer writes that the openness of a standard is increasingly important to end users. This is understandable if we accept that openness implies: when multiple implementations of the standard from different sources are available, when the implementation functions in all locations needed, when the implementation is supported over the user-planned service life, and when new implementations desired by the user are backward compatible to previously purchased implementations (24). The model for open standards has an increasingly visible impact on the standardization process for creators, implementers, and users. West's Model West describes a stakeholder model in which there are five distinct groups with interests in open standards development. These classes are: "(1) technology providers, (2) incumbent vendors, (3) vendor challengers, (4) complement providers, and (5) users" (25). The model has similarities to Krechmer's simplified model. Technology providers
46

develop the technology on which the standard is based. Oftentimes, this group also accounts for the implementers in Krechmer's model.
Vendors consist of implementers who do not have control of the technology development but do provide products that implement the standard. This group consists of incumbents--those who lead the market and maintain a significant segment thereof-- and challengers--market leader competitors who wish to disrupt the control of the market. This challenger group sometimes will create standards alliances or consortia to gain control of the market or, perhaps more accurately, to level the playing field (25).
Complement providers are those who provide complementary products for a given standard. These providers' interests are driven primarily by volumes--they desire large market shares for their products with little regard for high profit margins. In other words, they are interested in providing products that piggyback on the successful implementations of a standard. Users, once again, make up the same group of stakeholders as in Krechmer's model. This group ultimately cares about the interoperability of the standard and the resultant benefits derived from achieving interoperability.
We can apply West's stakeholder model to the public transit industry, particularly as it pertains to real-time passenger information. Technology providers are those companies that develop and, more often than not, also implement AVL technology. Many of these same companies compose the group of incumbent vendors. Vendor challengers are more difficult to pin down in this model, but Google and its decision to lead the development of the GTFS-realtime open standard most accurately represents this model. Google has been a disruptive force in the provision of transit data (and a number of other sectors), most notably with the development of GTFS.
There are a number of other vendor challengers engaged in the GTFS-realtime "consortium," but the active members of this group mostly seem to be complement
47

providers. We can think of complement providers in this model as third-party application developers, looking to provide real-time passenger information via apps that piggyback off of information provided via AVL systems. They care not about developing a highcost, custom solution for a single agency, but rather reaching a large number of users-- what we will consider as agencies here.
The question of who the user is somewhat conflated because our public transit agencies are direct users, but ultimately their customers are the beneficiaries. So here we have two sets of users: direct (agencies) and indirect (transit riders). Considering this basic model of stakeholders in the transit industry will be important for understanding stakeholder relations and interests in the case studies in Chapter 4.
Public Policy and Standards Development
Government institutions have substantial influence over standards development not only through the institutions through which they act but also through the public policy they support. Greenstein and Stango note the importance of government decisions in backing standards because of the power to mandate compliance with a given standard. However, the incredible rarity of occasions in which these compliance decisions are reversed is just as important for understanding the role of government in standards development (29). The literature provides ample discussion of the benefits and costs of government intervention as well as the conditions under which intervention is most appropriate.
David and Greenstein, drawing on the work of Besen and Johnson on Federal Communications Commission (FCC) regulatory intervention, indicate the conditions under which different types of intervention may be appropriate. Key among their recommendations are "government should not mandate standards if these are likely soon to require revision... symptoms of ineffective or premature actions should not be
48

ignored--including negative industry reactions and continuing attempts to break from mandated standards... [and] sparse response to a [standardization] proposal may indicate premature action [by the intervening agency]" (30, 31). While the latter two recommendations may be applied retroactively to standardization proposals, the first applies to standardization processes where government has yet to intervene.
While the authors recognize the numerous arguments for intervention to achieve gains in efficiency, David and Greenstein note that there are issues that come with government activity in standards development. These issues nearly all stem from the role that stakeholders are able to play in the process. Typically, vested interests, or incumbent vendors, are the most well represented and gain the most influence in a standards development process. Consequently, old standards will be systematically protected while new stakeholders will likely not be fully represented nor even identified in the process (30).
Cabral considers ten different standards battles and the role that government policy has played and can play in favoring or supporting a competing standard. He considers two questions of import for policymakers: which standard to support and when to intervene. For the first question, Cabral argues that a patient policymaker should support the lagging standard, or the one that is likely to prove worthwhile over the long term but has yet to fully mature or see market dominance. The policymaker in a hurry, on the other hand, should back the current leading standard. As to when a policymaker should intervene, the answer is binary again: the patient policymaker should delay any action, the impatient should act now (32).
The definition of patience and impatience is, then, at the crux of this theory and how policymakers should react to standards battles. Cabral suggests that this depends on both the policy context, e.g., US vs. Europe vs. Japan, and the industry/technology in question. For example, a government might favor the more centralized, impatient
49

approach of choosing a product early over allowing competitive forces to work through markets (patient). When considering the technology in question, some product cycles are relatively short, which would favor an impatient approach to avoid lagging.
Farrell and Shapiro consider the differences between these policy contexts in the selection of high-definition television (HDTV) standards. Japan and Europe chose a much more centralized approach, demonstrating characteristics of impatience. Each chose a technology-firm combination very early on and supported it through the development of the technology. On the other hand, the United States utilized the resources of competing firms in the HDTV standard selection. Additionally, in the United States terrestrial broadcasting interests carried significant political weight, so displacing these providers by adopting a standard too early was out of the question for the FCC. These differences materialized in a long delay in standard setting and technology development in the United States, yet a side effect of this delay was an improvement in the ultimate technology outcome.
In the United States, the FCC allowed for competitive systems to develop in tandem until it chose a standard from a selection of proposals by 1993 (33). At this point, tests were prepared to determine which HDTV proposal was deemed best. The results of the February 1993 tests were, of course, inconclusive. In order to keep development costs down and avoid further competition, companies and organizations involved formed a Grand Alliance to cooperatively set the standard and build a working prototype. Eventually, this group submitted a proposal that is very close to what would be approved by the FCC in 1996 (34).
This case shows a very patient policymaker in the FCC, which chose to allow competing firms to generate multiple proposals. In turn, this led to these competitors allying themselves in order to reduce duplication of efforts and bring HDTV to the market more rapidly. So, the patient policymaker led to a better standard by creating impatient
50

market actors willing to collaborate. While this is just a single example, it demonstrates some of the reactions policymakers have in different environments and lays a foundation for understanding how policy context and technology influence patience.
De facto vs. de jure An important distinction in the world of standards development is de facto vs. de jure, or whether a standard is formally adopted/sponsored or not. The question of "who is the formal adopter/sponsor?" poses difficulties in itself. Yet, typically, de facto standards achieve widespread dominance by the action of markets without the formal requirement of a governing body, whereas de jure standards exist under the governance of an accredited SDO. The examples from FCC above primarily describe activities around quality or safety standards enforced by the regulatory body. However, this regulatory activity is less prevalent for ITS transit interface standards. Technically, there exists no de jure standard for transit ITS products because the USDOT has not formally adopted any standard, including the FTA/APTA TCIP. Nevertheless, the USDOT does support standards development activity through accredited standards bodies such as APTA, ITE, and ANSI. Fleming Waguespack (2005) Internet Engineering Task Force (IETF) is an example of de facto standards-setting body even though it is challenged by traditional standards and governmental bodies. The most popular product will also be the de facto standard, and setting a standard can offer a product a dominant market position. Thus, de facto standard setting in these cases is of enormous concern to firms in systems industries and will often be central to their business strategies (35).
51

Technical Dimensions of Standards Thus far, this review has covered "soft" or social dimensions of data standards.
These social components of economic and institutional analysis are critical to a complete understanding of the motivations and interests in standards development. It will be useful, however, to explore the technical dimensions of standards in order to refer to phenomena by their proper names.
In the taxonomy of standards laid out by David, there are three classes of standards: reference standards, which enable the accurate measurement and comparison of different products (i.e., benchmarking); minimum quality or safety standards, such as the expected lifetime or performance of an electronic component; and interface standards, those standards which allow a sprocket developed by Sprockets, Inc. to communicate with a widget manufactured by Widgets Corp (36). Other researchers' taxonomies include additional classes, such as variety reduction standards, which "limit a product to a certain range of characteristics such as size and quality level" (for example, reducing the number of types of screws) (37); however, this research will focus on the importance of interface standards to the functioning of passenger information dissemination and the market that supports such activity. Interface and Compatibility Standards
Interface, or compatibility, standards describe the functional or physical characteristics that are necessary for equipment or systems to exchange information successfully. The standards contained in this research (SIRI, GTFS-realtime, and TCIP) are all interface standards, defining the format, structure, and content of the real-time information exchanged by onboard AVL systems to central servers to third party consumers (either users or application providers). While the exact chain of
52

communication intended for each standard may differ, the basic function of compatibility exists throughout.
Interface standards for IT, while relatively new to the public transit industry, have been considered previously in academic literature. In 1998, Hickman reviewed the current state of the practice for interface standards. His review included a survey of 300 software and hardware product vendors in the transit industry. The resultant response rate of about 9% (only 27 fully usable responses) perhaps indicates a lack of interest in the topic matter, a lack of knowledge, or a desire to remain silent on the subject. Whether this response rate is indicative of a particular stance on the topic or simply the consequence of happenstance, Hickman does note that his sample may be seriously biased and should be "viewed with healthy skepticism" (38).
Open Standards Development
Standards development takes place in a variety of settings under different institutional arrangements and technical requirements. However, all of the standards considered in this paper have one thing in common: they all claim to be open standards. An open standard is simply a standard that is "not under the control of a single vendor and is easily available to those who need it to make products or services" (39). This is a rudimentary definition because there are many facets of openness, which will be considered below. This section will also explore related "open" movements and the interaction between these trends and open standards development. Components of Open Standards
There are of course, a wide array of definitions for what makes an open standard. Krechmer documents a few of these, which range from West's availability beyond the standard sponsor to Perens' definition which draws from the open source software movement. Perens emphasizes not just the development and availability of a standard,
53

but also the accepted practices and operating for a standard. His fundamental list of principles and practices include:
1. availability, 2. maximize end-user choice, 3. no royalty, 4. no discrimination, 5. extension or subset, and 6. predatory practices (40). Krechmer recognizes the importance of different stakeholder groups to open standards: if a standard is only open for users and not creators, it is not truly open. For creators, the development process must allow for open meetings, certain consensus criteria, and formal procedures, such as balloting. Implementers have market needs upon which an open standard must not impinge--namely, that the standard should not impose burdensome costs, keep them from innovation, or put them otherwise in a negative market position. Similarly, users consider a standard open when there are multiple implementations to access--such as the availability of GTFS from multiple transit agencies--and there is sufficient support for the standard. Krechmer's ultimate definition, therefore, defines ten requirements that draw upon the expectations of openness from each of these stakeholder groups: 1. Open meeting requires that all stakeholders can participate in meetings; different levels of barriers (economic, physical distance) can detract from an SDO meeting this requirement. 2. Consensus decisions on standard should be made by consensus, a term that has a range of meanings; however, Krechmer views compliance with this requirement to be binary.
54

3. Due process requires that "consideration be given to the views and objections of all participants" and that processes exist for participants to express such perspectives.
4. Open world suggests that any standard shall, in principle, be applicable to use cases around the world. In other words, it should not be restricted by national or political boundaries. However, because there are often regional or cultural issues involved with standards, the requirement focuses on the geographic coverage in which the standard operates.
5. Open Intellectual Property Rights (IPR) refers to the license that governs the use, redistribution, or commercialization of a standard for implementations. Krechmer scales this requirement in five levels from 0 to 4 ranging from 0 commercial licensing to 4 no copyright/patent protection.
6. Open change is a somewhat redundant requirement in which Krechmer bundles the first three requirements (open meeting, consensus, and due process). Nevertheless, the requirement does indicate an important characteristic that relies on the convergence of key principles and so may justify being addressed separately.
7. Open documents requires that documents for the standard development process are made open. This includes "work-in-progress documents" (e.g., draft versions of a standard, meeting discussions, technical reports, etc.) and "completed standard documents." Krechmer describes three states of open documents:
1. Work-in-progress documents are only available to committee members (standards creators). Standards are for sale. (Current state of most formal SSOs.)
2. Work-in-progress documents are only available to committee members (standards creators). Standards are available for little or no cost. (Current state of many consortia.)
3. Work-in-progress documents and standards are available for reasonable or no cost. (Current state of IETF) (24)
55

8. Open interface prescribes that standards support both backward and forward

compatibility. This category could be broken down into connectivity, or how devices in

different spatial locations interact; extensibility, allowing modifications to standards that

do not break compatibility; and adaptability, allowing for changes in communication

system.

9. Open access is a somewhat nebulous requirement that Krechmer seems to

attach more to safety standards than interface standards. Nevertheless, it could be

interpreted to indicate the degree of access users have to implementations of the

standard or the availability of conformance verification tools to verify compliance.

10.

On-going support requires that a standard be supported during the

four phases of its lifetime (following creation): fixes, maintenance, availability, and

rescission.

According to Krechmer, these requirements fully satisfy the Perens definition of

open standards, including both principles--One World holds that a single standard ought

to perform a capability globally, for all cases--and practices--Open Meeting requires

that any and all may play an active role in standards development. Table 3 shows how

the ten requirements of Krechmer's definition apply to the three stakeholder groups. The

table indicates that three requirements--One World, Open IPR, and Open Change--

impact all three stakeholder groups. Users and implementers rely on nearly all of the

same requirements, except that implementers do not rely on on-going support.

56

Table 3: Importance of open standards requirements to different stakeholders (24)

Requirements
1 Open Meeting 2 Consensus 3 Due Process 4 One World 5 Open IPR 6 Open Change 7 Open Documents 8 Open Interface 9 Open Access 10 On-going Support

Stakeholders

Creator

Implementer User

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

In addition to a robust definition of open standards, Krechmer provides an analytical framework for assessing open standards development. Because the author uses this framework for assessing passenger information standards in the chapter on case studies, Krechmer's ten requirements, and their relevance for transit ITS standards, will be further explored in Chapter 4. Related "Open" Movements
In recent years, a number of technology-centric movements labeled with the "open" qualifier have emerged. The author has cursorily reviewed open data with respect to the White House's policy stance and its potential impact on standards development. This brief section is to clarify this and other movements and their relevance for this research. Open Data
Perhaps the most recent open movement and the one most successful at capturing the public eye has been the "open data" movement. Open data refers to the idea that datasets, particularly those owned by the government, should be made openly
57

available to any private citizen or company that wishes to use them. In addition, the movement holds that governmental agencies should provide such data in machinereadable, common data formats so that they may be easily parsed by software developers, researchers, and any other interested party. Open data holds a strong connection to the world of open standards because the success of the movement relies on being able to build robust, repeatable applications that function for both Agency X and Agency Y. In other worlds, interface standards must be used by a large group of agencies in order for users to experience the benefit of network effects. Open Source
The open source software movement is a relatively new concept, but has already had profound impacts on the software development industry. Open source refers to a software development model that promotes free redistribution of software and software components, makes source code (not just compiled code) openly available, and allows derivative works (41). There are a variety of licenses under which open source software is published (42), ranging from the very permissive (for example, reuse for commercial purposes) to more restrictive policies on how source code may be used.
The roots of the term "open source" grow very much out of the world of standards. The term was coined in a Palo Alto, California, strategy session following the decision to publicly release the Netscape Navigator source code (27). Netscape was embroiled in longstanding "browser wars" with Internet Explorer (IE), which it eventually lost. The ultimate conclusion of these wars, however, would spark the open source movement and the eventual destruction of IE's hegemony by open source browser projects such as Mozilla Firefox and Chromium (the open source basis for Google Chrome).
This movement has since grown astronomically, especially over the past decade. Figure 3 shows the exponential growth in the number of source lines of code contributed
58

to open source repositories tracked by Deshpande and Riehle over the period of January 1995 to December 2006. While this study is a few years old, the trend line is unmistakable: the open source community is growing rapidly. According to the authors, "the total amount of source code and the total number of projects double about every 14 months" (43).
Figure 3 Growth of open source lines of code from 1995 to 2006 (43) While the open movements discussed here have distinct meanings, they do not
exist in isolation. It is likely that as open data and open standards proliferate, so too will the number of open source projects and lines of code dedicated to using these data and standards. This correlation is not a given, yet the interest in civic hacking (44) and viewing government as a platform (28) suggest that these movements will work together in concert and continue to exhibit this exponential growth pattern.
59

Real-Time Transit Standards Development
Methodology
The methodology presented here relies on the multiple case study to understand the standards development processes utilized by each data standard. One of the principle aims is to reach an understanding of how "open" each data standard is, or how well each data standard complies to the definition of an open standard. According to Yin, a case study is an empirical endeavor that investigates contemporary phenomena within the context in which they occur. A case study provides a method to observe both the phenomenon and the contextual details--which may be part of what the observer seeks to understand (45).
The multiple case study methodology used here relies heavily on document review and past surveys on agency attitudes and capabilities regarding the provision of realtime information to understand characteristics of the standardization processes and their impacts on agency adoption. Interviews were also conducted with members of the SSOs from each of the standards development processes. The final source of information is a collection of articles from a variety of peer-reviewed journals that contain data about various implementations of (1) products deployed by different vendors, (2) standards implemented in different use cases, and (3) opinions/perspectives on standardization and ITS for transit.
Justification for Case Study Methodology
The case study as methodology offers research on systems, processes, and institutions an important tool for understanding. Yin offers the following purposes for choosing this methodology in research:
1. The research seeks to answer a "why" and/or "how" question, 2. The research focuses on contemporary events, and
60

3. The researchers lack "control over behavioral events" relevant to the research (45).
The research objectives in this thesis are to understand why and how each of the real-time transit passenger information standards development processes function and to consider how the standards environment could be improved for the better functioning of real-time information provision. This is certainly a contemporary subject of review. While there are some historical considerations, each of these standards is actively evolving over time and each of the respective SSOs consider the future of the standards.
Finally, the researcher draws on insights from members of the SSOs and does not attempt to nor could he control the behavioral events of these bodies. Any analysis of standards development processes necessarily must draw on case study findings, lest the research be focused on developing economic models or theoretical insights. This research, on the contrary, seeks to understand specific real-world processes and institutions and their respective arcs of development.
Components of Case Studies
Interviews To gain insights into the history and evolution of the standards development process, the researcher conducted interviews with either members of the SSO or persons actively engaged in the standardization process for each data standard. The nature of these interviews were primarily informational, seeking specific facts about the operations and functioning of standards committees rather than opinions or speculations. The major categories for questions asked in the interviews are as follows: Interviewee's role in standard development History of standard development process Meetings, Consensus, and Formal Processes
61

Intellectual Property Rights, Global Availability Transparency, Interface, and Access Support for Implementers Many of the question topics aimed to understand the openness of the respective standard development process according to Krechmer's ten principles of open standards. Internal Review Board approval was obtained for the interview questions and consent from interview participants was obtained. Although these interviews were informational, in order to protect the participants pursuant to human subjects policies, their names are excluded from this thesis. Nonetheless, many parts of the interviews informed the case study analysis. Document Review The researcher extensively reviewed documents on the standards and their respective standardization processes. These documents include SSO and/or data standards websites, documentation on current and/or past versions of the data standards, and any publicly available meeting minutes or committee communications. Many of the most important of these documents are referenced in the bibliography and are available on the Internet. However, if at some point in the future, these are no longer available at the URLs provided, please contact the researcher4 for a copy of the reference material (given that the license governing the use and distribution of the content permits such sharing). Assessment of Openness Openness is an important characteristic for standard setting that the researcher has identified in the literature review. As mentioned above, many of the interview questions were directed at understanding how well the standard satisfied Krechmer's ten principles
4 This researcher may be contacted at lreed3@gatech.edu.
62

of open standards. A brief description of the most salient features of openness is provided for each case study and a comparative review according to Krechmer's principles is provided at the end of this chapter.
Review of Outcomes Achieving standardization requires more than simply developing a standard. This is only the first step in a process that, if successful, will lead to the widespread adoption of the standard, the proliferation of network effects to both firms and users, and an improvement in the functioning of the industry market. As such, it is important to review the present outcomes in adoption of each of the standardization processes as indicators of how successful each standardization process has been to date. This is, of course, an ever-changing situation as implementation decisions are made and procurement documents produced in agencies every day. However, there is value in ascertaining the current state of affairs in order to both predict future trends and understand the process that led to the present state.
Case Studies
GTFS-Realtime
Background History GTFS-realtime is the real-time complementary standard to GTFS, the General Transit Feed Specification, which contains static schedule information for a transit agency or collection of agencies. The history of GTFS-realtime is tightly coupled with that of GTFS. Portland's Tri-County Metropolitan Transportation District of Oregon, more commonly known as TriMet, worked with Google to originally develop GTFS. Bibiana McHugh is mentioned as having initiating conversations with Google, Yahoo, and Mapquest in a desire to make transit trip planning information as readily accessible
63

as driving directions on popular mapping services (46). Chris Harrelson, a Google employee, was already engaged in the integration of transit options to Google Maps. By December 2005, TriMet's schedule information was available on Google Maps as Google Transit (46).
A number of agencies followed TriMet's lead. Nearly a year later, Google announced that the company had added five more cities to Google Transit (47). A change proposal was later made in 2009, and shortly thereafter adopted, to rename the GTFS standard (it was originally known as the Google Transit Feed Specification) to more accurately capture its growing use in many other applications besides Google Maps (48). Indeed, the standard has since grown to be adopted by nearly 700 agencies worldwide .5 In the U.S., 272 transit agencies had adopted open data policies to provide their GTFS feeds to the public as of March 2013. Figure 4 shows this trajectory of growth and when Google decided to tackle the issue of providing real-time transit passenger information.
5 According to the website http://gtfs-data-exchange.com (accessed on November 7, 2013). This figure includes both official and unofficial feeds as well as some agencies that may have out-of-date feeds. Nevertheless, the scale of this figure is accurate.
64

Figure 4: Adoption of GTFS by U.S. transit agencies (49).
Once Google was in the business of providing scheduled transit information, the provision of real-time information followed a natural progression. In the summer of 2011, Google launched Live Transit Updates for Google Transit for Boston, Portland, San Diego, San Francisco, Madrid, and Turin (50). This service provides real-time updates on transit vehicle arrival times as well as service modifications/alerts within the Google Maps trip planning function.
The real-time arrival time updates for Live Transit Updates relies on a bulk-delivery data standard known as GTFS-realtime, which Google developed with the help of partner transit agencies listed above as well as a number of individuals involved in the development of applications for transit. The specification, in secret development for about a year before its release, was made open following its release. Thus, GTFSrealtime brought to real-time passenger information what it had done to static information
65

only a few years ago: introduced a robust open standard for moving data from agency and vendor coffers into the hands of third-party developers.
Scope Google developed GTFS-realtime in order for the company to consume real-time transit feeds in Google Transit. As such, the standard differs in two fundamental ways from TCIP and SIRI, the other two standards considered in this research, which were developed primarily for intra-agency interoperability and communication. First, whereas TCIP and SIRI each allow for payloads of data at the transit vehicle level, GTFS-realtime provides a data payload only for an entire fleet of vehicles, what is often referred to as a "snapshot" of the transit system. While some agencies might have hundreds or even thousands of active vehicles at any given moment, GTFS-realtime is able to efficiently handle these data because it utilizes the lightweight Protocol Buffer data structure up to 10 times smaller and up to 100 times faster than XML serialized data (51). This model differs from utilizing a transactional application programming interface (API) such as the representational state transfer (REST) model that many agencies choose to publish and SIRI has recently adopted as a transport architecture. These transactional models allow for a more active conversation between interfaces. For example, a client-based web application may make transactional requests to an API for the next real-time arrivals for a specific stop (the next five buses to arrive at 5th St and Main St). The second fundamental way GTFS-realtime differs from the others is that it operates on a strictly one-way communication model. That is, an agency publishes GTFS-realtime for external bulk consumption. TCIP and SIRI offer more capabilities for integrating real-time passenger information with operations. For example, TCIP was developed with the architecture of an entire transit agency in mind. TCIP allows for operational need to connect, for example, a bus AVL system to other on-board
66

equipment. Similarly, SIRI allows buses to communicate with one another to, for example, ensure that a timed transfer is made smoothly by informing Bus B to wait for the passengers of Bus A if Bus A is running late.
Although these models may differ fundamentally, the primary concern of this research is the delivery of real-time information on stop arrivals/departures, vehicle locations, and service alerts. All three standards perform this function, whether they function at the junction between bus and agency server, agency server and agency web/sign interface, or agency server and third-party interfaces. The open data paradigm has shifted many progressive agencies from keeping data within intra-agency networks to sharing these data outside agency walls. Whether agencies commit to a fully open or semi-open model, the need for an effective data standard for real-time passenger information remains.
Technical Documentation The documentation for GTFS-realtime (52) provides an overview of the standard, description and examples of the feed types, and a complete reference of the specification. The standard has categories for three types of real-time information: Trip updates delays, cancellations, changed routes Service alerts stop moved, unforeseen events affecting a station, route or the entire network Vehicle positions information about the vehicles including location and congestion level (52). These categories provide for most, if not all, of the crucial information about transit service that passengers might be interested in. Certainly, there are more complex pieces of real-time information that are left unaccounted for here, such as information about connections/transfers between routes or detailed data structures about transit facilities. The technical specifications for SIRI, discussed below, capture much more of
67

this type of information and allow for more transactional data exchange models. However, the bulk exchange model for GTFS-realtime requires the specification to be somewhat more minimal than it might otherwise be. This does, however, help the standard to maintain a limited scope and agencies to achieve implementations more easily.
Development Institutional Involvement The primary institutions involved in the development of GTFS-realtime are Google and the original six transit agencies who participated in the closed development process. Since then, the specification has been adopted by a few more agencies (although the precise number is difficult to come by). Google staff work actively to coordinate with agencies on bringing them onto Google Maps and, by extension, onto the GTFS specification. Evolution The history of institutional involvement for GTFS seems to have been instructive for Google with its foray into real-time data. The company developed GTFS with the benefit of transit industry expertise from a single agency. When the specification was released publicly, there were initially a number of changes proposed and adopted almost immediately. It is likely that Google revised its development strategy and institutional involvement to include additional partners partly because of this experience. Another possible explanation for this change in institutional involvement is that the company wanted to expand its reach for bringing the standard around the globe by releasing Live Updates for Google Transit with an international scope. Regardless of the reason, the development of GTFS-realtime included a broader group of stakeholder institutions, which has likely contributed to a decrease in post-release changes to the standard (see Figure 5).
68

Number of documented changes

12

10

8

6

4

2

0 0 1 2 3 5 6 7 8 9 13 14 17 23

Months after initial release

GTFS-realtime

GTFS

Figure 5: Number of documented changes for GTFS vs. GTFS-realtime (53, 54)

Another crucial piece of the evolution of GTFS-realtime is the growth in "repeaters" that exist for the standard, or small applications that convert a different specification to GTFS-realtime. Repeaters allow agencies that have real-time passenger information in one format to gain the benefits of an open standard like GTFS-realtime. Currently, the known repeaters for GTFS-realtime were developed for use in OneBusAway, the open source suite of tools for delivering passenger information. The repeaters include support for the NextBus, SIRI (Vehicle Monitoring and Situation Exchange), and Orbital OrbCad AVL (55). While this bandaid solution to interoperability is not perfect (especially for a proprietary format that could change at a moment's notice) and it may be impractical to consider for every possible proprietary closed format, it does begin to expand the sphere of influence of GTFS-realtime and, importantly, allows for easy integration with the SIRI open standard.

69

Openness GTFS-realtime is notable for the openness and transparency that governs it today. Nevertheless, the standard was originally developed in the product development shroud of Google secrecy for which the company is renowned (or notorious, depending on the perspective). Original participants in the development of the specification signed nondisclosure agreements in order to keep the details of the project closed. This is truly the antithesis of openness; however, a participant of the process notes that in the realm of standards development, the barriers to initial development and publication are high. This closed process allowed the participants to quickly develop the specification and deploy implementations in the absence of painstaking and meticulous debates with a wide array of stakeholders. With the release of the standard in 2011, Google removed the barriers to widespread participation. Open communication is maintained on a publicly-accessible mailing list (https://groups.google.com/forum/#!forum/gtfs-realtime). Change proposals, technical issues, and clarifications are all discussed on this forum by an active community of agency staff, Google staff, and transit application developers/enthusiasts. The general policy on changes to the standard is carried over from the policy governing GTFS. That is, in order for a change to the standard to be considered, it must see interest both from application developers and transit agencies. The policy is intended to keep the standard from becoming bloated with superfluous data and relevant for all stakeholders. As for intellectual property rights, the specification is published under the permissive Creative Commons Attribution 3.0 License (56) and all code samples are available under the Apache 2.0 License (57). Success As mentioned previously, the static GTFS specification has been adopted by hundreds of transit agencies around the United States and around the world. Because
70

the GTFS-realtime feed works in conjunction with GTFS, it stands to reason that many agencies will invest in making their schedule information work seamlessly with their realtime information. While this sounds simple on paper, in reality, many agencies that have AVL and scheduling systems will have different vendors providing each system. Applications that deliver real-time information along with scheduled information (e.g., to provide information on route geometries and stop locations along with real-time arrival times) require the reconciliation of object identifiers in schedule and real-time systems. In other words, trip identifiers or route identifiers in the schedule must match (or be translated to match) those identifiers in AVL systems. Nevertheless, GTFS and GTFSrealtime appear to be in a strong position to serve that role, especially thanks to the support of real-time "repeaters" that translate the NextBus API specification, SIRI, and others into GTFS-realtime (58).
TCIP Background History The development of Transit Communication Interface Profiles (TCIP) was initiated
by the USDOT's Intelligent Transportation Systems Joint Program Office (ITS JPO) in November 1996. Industry professionals came to the realization that in order for transit technology systems to move forward in a progressive and constructive way, standards needed to be an essential part of the conversation. The standard, funded by the ITS JPO and originally developed by the Institute of Transportation Engineers (ITE), switched ownership to APTA in 2001 primarily because of APTA's stronger expertise in the transit industry (59). It was under APTA that the bulk of the standard was developed.
71

Scope The primary goals of TCIP are to achieve intra- and inter-agency interoperability and to decrease the negative effects of vendor lock-in. These goals are in direct agreement with the federally-mandated concept of regional ITS architectures. However, another one of its goals according to an APTA presentation from 2010 is to lead to interoperability "between an agency and external Information Service Providers" (60). This goal of interoperability with Information Service Providers suggests that the TCIP standard might cater to the recent growth of application developers that have latched on to the open data movement in order to provide information to transit customers. This is indeed an important goal, but may be difficult for TCIP to fulfill simply because of the sheer flexibility and customization that the standard allows6. Technical Documentation The documentation of each version of TCIP (including the current version) is currently hosted on the APTA TCIP website in the form of zipped MS Word documents (61). The standard itself is expansive, providing XML-formatted schema for nearly every type of transit technology subsystem and business area imaginable including: Scheduling, Passenger Information, Onboard Systems, Common Public Transport, Control Center, Fare Collection,
6 TCIP provides an expansive "menu" of options that can be specified for a given product/interface. For example, there may be 40 different fields (some of which may be required) for a certain message type. However, one vendor in compliance with TCIP may specify ten of these fields for its product, while another vendor specifies ten different fields. Both may be TCIPcompliant, but the interoperability is not necessarily ensured. This is, of course, a concern with any flexible standard, but the breadth of TCIP makes it especially so.
72

Spatial Referencing, and Transit Signal Priority (TSP) (62). Figure 6 shows a diagram of the expansive TCIP Model Architecture. The standard provides building blocks from these schema out of which systems engineers can build interfaces that are compatible with one another.
Figure 6: Diagram of TCIP Model Architecture (60) TCIP allows for the construction of system interfaces through a hierarchy of data
"elements" that compile into "frames" which compose "messages" that are passed between interfaces in "dialogs" or data exchanges. Figure 7shows a diagram of this hierarchical organization. This extremely flexible system allows for an immeasurable number of combinations and permutations for systems to communicate with one another. In practice, there may be need for only a few sets of standard messages to
73

send between, for example, a CAD-AVL system and Web-based trip planner. The developers of TCIP have accounted for this by making standard message sets available through TIRCE (TCIP Implementation Requirements and Capabilities Editor), an application that allows users to build custom message sets and dialogs.
Figure 7: Diagram of conceptual hierarchy for TCIP building blocks (60) Development Institutional Involvement While the TCIP standard development process began under ITE, the standard
underwent the bulk of its development and refinement while under the direction of APTA. A series of technical working groups (TWGs) composed of a mix of transit agency staff and vendor representatives developed the definitions and schema for TCIP. A TWG
74

existed for each major business area with an additional one for Tools (TWG 4), for a total of 10 TWGs.
An examination of the Passenger Information TWG (TWG 2), for which real-time passenger information messages and elements are defined, shows the institutional makeup of those involved in the standard development process. Figure 8 shows the breakdown of institutional involvement in the Passenger Information TWG. The vendor category is comprised of consultants to APTA, technical staff, and managerial staff. The agency category is comprised of technical and managerial staff from transit agencies. The TWG category is made up of APTA staff.
Figure 8: Participants by sector in TCIP Passenger Information Technical Working Group (63)
From this chart, it is clear that vendors make up the largest bucket of institutions involved in the standard development process with 27 representatives; agencies make up the second largest group with eight representatives; and TWG staff and academia are the smallest groups with one and two members, respectively. Although, the number of representatives listed on a contact sheet for the TWG is a primitive means to begin to
75

understand the interplay and influence on the standard development process, in the absence of complete and organized minutes of past meetings, it offers a glimpse at how institutions were represented in this process. According to Lehr, there are many scenarios of strategic decision-making that occur within standardization committees. For example, new market entrants and entrepreneurs are more vulnerable to delays and so stable, incumbent firms may attempt to delay standardization outcomes (64). Nevertheless, this process necessarily incorporated vendor input because these firms often know many of the technical issues facing standardization firsthand.
Evolution Most of the development work for TCIP was completed around 2006. The standard moved from active development to a five-year review cycle at that time. A comprehensive analysis on the changes made to TCIP is more difficult than for GTFSrealtime or SIRI (see next section). The TCIP documentation is extremely lengthy, and each version is contained within a series of word documents. This document structure makes a comparison very cumbersome at best, impossible at worst. The versions are, however, labeled according to software numbering conventions and number at a total of fifteen versions (from version 1 to the current version 4.0). The most noteworthy change for this research appears to have come in TCIP version 3.0.5.2, which was issued on March 1, 2012 (65). In version 3.0.5.2 of TCIP, a GTFS timetable importer was included in the standard. While prior to this version TCIP has made reference to a number of other industryaccepted standards, these other standards have all been maintained by accredited SDOs. This is the first acknowledgement that, in some areas, de facto standards and specifications have an important role to play. Indeed, before GTFS, there were no de facto standards adopted so widely to be worth including. However, it appears that when hundreds of transit agencies (large and small) began to move towards a specification,
76

APTA took notice and decided to adopt the specification (albeit only as an importer) into its transit standard family.
Openness The standard development process for TCIP itself was open and transparent, allowing any interested party to be involved in the development or comment on version. APTA's standard development process is modeled after that of the American National Standards Institute (ANSI), a well-established voluntary consensus standards development organization, whose membership comprises "more than 125,000 companies and 3.5 million professionals" (66). When it comes to transparency, though, there are some issues related to communication of information regarding the TCIP standard. On the one hand, there is a wealth of information available on the standard's website. Such information includes all previous versions of the standard, archived meeting notes, free support tools for working with the standard, TWG member lists and meeting attendee lists, a database of comments on the standard, and more. While the number of archived documents is impressive, the organization of the material is confusing. Just as the documentation for changes between versions is buried deep within large MS Word documents, so is the information contained within these archives. The content is searchable via a well-indexed search engine, but the organization of the website is poor and nearly all content is in the form of sizable MS Word documents that must be downloaded and parsed through. Success Measuring the success of TCIP by the number of implementations for real-time passenger information would suggest that the standard has achieved less than it truly has. There is no good indicator of how many agencies use TCIP to communicate realtime passenger information either within an agency or to a third party. The only well-
77

documented instance of TCIP used for real-time passenger information is the pilot project developed at LYNX (67), the Orlando-area system operated by the Central Florida Regional Transportation Authority. This implementation of TCIP, however, will likely be discontinued in the near future according to the interview conducted for TCIP. This is not to say that the standard is not used in other business areas and for related purposes. There have been a number of other pilot projects around the country, including at King County Metro, Maryland Transit Administration, and Chicago Transit Authority. In fact, New York City Metropolitan Transportation Authority utilized modified parts of the standard for a recent project7 to deliver real-time information to customers (68). Additionally, a recent Transit Cooperative Research Program (TCRP) synthesis on electronic passenger information signage in transit reported that six other agencies in the U.S. (not counting NYC MTA) utilized TCIP for real-time passenger information (69).
While there are a number of projects that draw on TCIP, the standard is far from achieving its goals of providing intra- or inter-agency interoperability. While these goals might have been achieved in a few cases around the country, TCIP has seen nowhere near the adoption rate of GTFS. Based on the integral relationship between GTFS and GTFS-realtime and other factors discussed in the GTFS case study, this author conjectures that the same dominance will hold true in time for GTFS-realtime. While TCIP may continue to play an important role in ensuring interoperability between subsystems beyond real-time passenger information and in enabling the pursuit of custom solutions (such as with NYC MTA), it is likely that it will be dwarfed by GTFSrealtime as it continues to grow into new markets.
7 The real-time information system is known as MTA BusTime (http://bustime.mta.info/).
78

SIRI
Background History Developers of the first version of the Service Interface for Real-time Information (SIRI) began working on the standard between 2004-2005 and the standard officially emerged as a technical specification under the European Committee for Standardization (CEN) in October 2006 (70). The standard is a result of the collaborative efforts from "equipment suppliers, transport authorities, transport operators and transport consultants from eight European countries" (71) including the Czech Republic, Germany, Denmark, France, Norway, Sweden, and the United Kingdom. SIRI draws heavily from France's TransModel for its conceptual framework, and the UK's Real-time Transport Interest Group (RTIG), Germany's Verband Deutscher Verkehrsunternehmen (VDV), and the EU Trident project provided valuable starting points for the development of the standard. Scope The development of SIRI brought together a number of national transit data standardization programs in order to more effectively address standardization at a broader scale. According to SIRI documents, the primary goals for developing the SIRI standard were to give purchasers of real-time systems "a straightforward, watertight way of procuring different components of a public transport information system from different suppliers" and to provide suppliers of such systems "a Europe wide market, ensuring that their systems can be used in every country without needing to implement different interface standards in each region" (71). Thus, the benefits were perceived to be directly attributable back to purchasers (or transit agencies) and suppliers (ITS vendors). An added benefit was the opportunity to
79

update existing standards (whether at the national level or for proprietary systems) to account for emerging technologies (71). So, whereas in the U.S., TCIP was the first standardization attempt (outside of proprietary specifications), SIRI was a "next generation" standard for a few nations that had already implemented national standards.
Technical Documentation Technical documentation for SIRI is available in English on the SIRI website in the form of a white paper (71) and, far more extensively, as a handbook (72). As with TCIP, SIRI extends far beyond the provision of passenger real-time information (though perhaps not quite so far as TCIP). Among its ten services shown below, or functional data categories, those in bold italics are those which are typically considered under the umbrella of real-time passenger information: Production Timetable (PT) provides information on expected (or scheduled) transit service for a day in the near future Estimated Timetable (ET) provides information on real-time deviations for the current day, or only those trips currently in operation Stop Timetable (ST) and Stop Monitoring (SM) gives scheduled information (ST) and real-time deviations (SM) at the stop level Vehicle Monitoring (VM) sends real-time information on the location of a transit vehicle Connection Timetable (CT) and Connection Monitoring (CM) gives scheduled information (CT) and real-time deviations (CM) to inform a departing vehicle on the need to wait for an arriving vehicle at a stop or station serving multiple routes General Message (GM) exchanges basic text messages between entities Facilities Management (FM) provides information on the status of facilities, such as elevators or escalators that are out of order
80

Situation Exchange (SX) exchanges structured messages between entities (68) While the Estimated Timetable, Connection Monitoring, and Facilities Monitoring services all provide real-time information that may be of value to the operations and even some customer use cases, they are not necessarily within the scope of this research. Stop Monitoring and Vehicle Monitoring, however, fall well within the definition of providing schedule deviation/adherence and vehicle locations. Development Institutional Involvement SIRI is the result of collaboration between a number of firms and governments throughout the European Union. Working group meetings for the standard are attended by representatives from each member country to CEN, although historically the most participation and interest have come from Germany, France, the UK, and Scandinavian countries. As mentioned above, a few national standards already existed from which SIRI draws a great deal. Because these standards already existed, some interesting accommodations were made in order to satisfy the interests vested in these preexisting standards. For example, in order that previous implementations of the German VDV standard might not be broken, two separate XSDs (XML schema definitions)--a nested and flat version--were maintained for some time. This is a peculiar example of how institutional and political values can outweigh the purely technical in standard development. Evolution Like GTFS and GTFS-realtime, a well-organized set of versions and their respective changes is maintained on the SIRI website (73, 74). A list of all changes made since version 1.2 (April 7, 2007) is maintained there, along with--beginning with version 2.0-- the country code of who initiated each change (e.g. Germany (DE), the United Kingdom (UK), France (FR), etc.). The SIRI standard began as a CEN technical specification, a
81

"normative document ... that would not gather enough as to allow agreement on a European Standard... or for providing specifications in experimental circumstances and/or evolving technologies" (75).
The most recent version of SIRI (2.0) was drafted into a proposal in order to become the more robust and rigorous European Standard (EN), a cornerstone of the concept of the Single European Market to facilitate effective trade both within and beyond Europe (76). This continued work and development on SIRI signal the standard's continued importance in European markets and even in the US, where the NYC MTA heavily incorporated the standard into its MTA BusTime project mentioned in the TCIP case study above.
Openness Much like TCIP, SIRI is developed within the confines of a formal, accredited SDO, the European Committee for Standardisation. As such, the standard development process is open and consensus-based, relying on a set of protocols that have been established for the review, adoption, and maintenance of many standards under CEN. Nevertheless, there are components of the SIRI standard that present barriers to open participation and implementation of the standard. For one, meetings for the standards are only open to participants of national committee members. Others may participate as observers, but only on an invitational basis. Further, while the license restricting the use of the standard only requires that copyright holders be acknowledged, formal standard documentation must be purchased via the national member sites (e.g., via VDV's website)8 and reproduction of any part of supporting standards produced by nonmembers is prohibited without permission from these copyright holders. These barriers
8 Purchase of the SIRI specification was confirmed by an interview with a participant in the SIRI standards development process. While there exist sites that host what appears to be the complete SIRI documentation free of charge (http://www.siri.org.uk/), the researcher could not locate the national member sites where documentation or schema were available for purchase.
82

to implementation and participation are minor, but remain impediments to becoming a fully open standard.
Success The continued and active development on SIRI points to its success as a standard, especially in European markets. However, the standard would not be under consideration had it not seen some interest and adoption in the U.S. market. NYC MTA is one of the agencies that continues to push the evolution and development around SIRI, having adopted it for MTA BusTime and pushing to add JSON (JavaScript Object Notation a lightweight, web-ready alternative to XML) formatting and modern web service transport methods to the standard (77). There are at least five other U.S. transit agencies reporting usage of SIRI in a recent TCRP Synthesis on the use of electronic passenger information signage in transit (69). Compared with the usage of either TCIP or GTFS-realtime, this is certainly a strong showing, especially given that this standard was imported from the European Union.
Comparison of Standards and Standards Development Processes
Assessment of Openness The framework used here to assess the openness of the real-time standards
considered in the case studies draws heavily from Krechmer's ten requirements of open standards. While the categories were interpreted slightly differently than his original descriptions to account for some of the idiosyncrasies of the requirements and to apply them more directly to this case, the open standard requirements remain largely unchanged.
The three case study standards (GTFS-realtime, TCIP, and SIRI) were each given a scoring for the ten requirements. Table 4 shows the scoring of these categories broken
83

out. The scoring methodology was taken directly from Krechmer, with a few modifications for this specific context.
The three open standards are considered alongside the NextBus API specification solely to compare with a closed specification from the industry. While TCIP and SIRI perform nearly identically in every category, GTFS-realtime earns higher marks in open meetings, open intellectual property rights (IPR), open change (a direct representation of its stronger performance in open meeting), and open documents. NextBus, on the other hand, being a closed standard shows a low openness index, although it does earn a few marks in the open world, open documents, and on-going support categories.
Table 4: Openness index scores for real-time transit passenger information standards
The results from the above table suggest that GTFS-realtime is a more open standard than either TCIP or SIRI, which are both managed through accredited SDOs. What explains this finding? Krechmer defines open standards as understood from the lens of open source software. This is a very democratic and distributed perspective that values not just consensus-based processes, but also the openness that is ascribed to fully open meetings that are held and recorded for posterity online. It also depends on clear, complete, and available documentation. It is in these areas where GTFS-realtime excels most. Any discussion of the future of the standard is discussed online in an open
84

forum. The IPR licensing is clearly stated and defined on the GTFS-realtime documentation (whereas with the others it is somewhat obscure). The documentation is fully available online and presented in a coherent, concise way.
Certainly, there may come a time when Google decides to move away from providing transit information (though this appears unlikely given its investment in the product worldwide). Yet because GTFS-realtime is so well documented and the content is clearly licensed, GTFS-realtime could easily spin off and continue to develop if the adoption and interest were great enough. It is for these reasons that GTFS-realtime scored higher on the openness index and perhaps why the standard may continue to flourish.
Implementations Each of the case studies examined the success of implementations for each of three
standards. According to data compiled from multiple sources, there appear to be similar levels of adoption for the standards (69, 78). Figure 9 below shows data from the 2013 APTA Survey on real-time information provision, indicating that the closed NextBus specification seems to hold the largest market share9. Even comparing with data from TCRP which suggests that TCIP has seven U.S. implementers and that SIRI has six, this observation holds true.
9 It is also worth noting that, although the survey indicates that 12 APTA member agencies have implemented NextBus, the NextBus website (https://www.nextbus.com/agencies/ accessed on August 2, 2013) reports that approximately 80 U.S. agencies have NextBus real-time systems (this includes APTA member agencies, some of which are duplicated in the list, as well as small university or circulator systems). This suggests remarkable rates of adoption for NextBus and is important to consider, yet this analysis will take into account only those agencies within the scope of this research, i.e. APTA member transit agencies.
85

Figure 9: Adoption of real-time data standards (78)
An important caveat to the standards' levels of adoption is a look at how these adoption levels have grown over time. This is, of course, a rough and imprecise measure because there are a variety of complex and difficult-to-measure factors that influence standard adoption (network effects, lock-in, etc.). Nonetheless, Figure 9 gives a picture of how quickly these different standards have seen adoption since their inception. Table 5 shows the average number of agencies that have adopted each standard per year. The year of inception is based upon the date that documentation was first made available. For GTFS-realtime and SIRI, there is a strong confidence that the year of inception is accurate. However, for NextBus and TCIP there may be instances where implementations were in place before the year shown.
86

Table 5: Average adoption rate for (agencies per year) for real-time standards (69, 78)
The above table shows that, even though it is relatively new, GTFS-realtime has the second highest number of agencies with implementations and the highest adoption rate (average agencies per year). This finding holds true with reasonable expectations for GTFS-realtime based on its integral relationship to GTFS, which hundreds of agencies have adopted in a period of approximately 7 years (estimated adoption rate of approximately 40 agencies per year). Assuming that Google continues to utilize GTFSrealtime for its products and the standard review process remains open to full public participation, it is likely that this adoption rate will continue to increase.
Recommendations
Moving Ahead for Innovation in the 21st Century
Effective real-time passenger information systems are crucial to satisfying customers' expectations and demands. Transit riders are adopting smartphones and still waiting for the bus. Budget-constrained agencies can deliver this information with relatively little infrastructure by making use of often pre-existing AVL systems and pursuing the open data policies already adopted by President Obama's administration. There are certainly costs associated with this approach, especially if AVL data are contained within a proprietary format. Nevertheless, the open standards that have developed over the past couple of decades allow a path forward to break vendor lock-in and reduce switching costs in the future.
87

While Moving Ahead for Progress in the 21st Century (MAP-21) addresses ITS in general ways and allocates some funding for ITS (79), there are some opportunities to address transportation technology and policy in the next-cycle authorization bill. MAP21 funding ends with FY 2014, so the next authorization bill will likely be introduced sometime before the current fiscal year ends. The President's Executive Order (EO) on open data for federal agencies offers an opportunity for the USDOT, specifically the FTA, to couple ITS improvements at the local level with open data initiatives. The framework to pursue these initiatives is in place--thanks to progressive agencies such as TriMet and others--should Congress find that such a policy is in the nation's best interest. Open data, besides being a force for government transparency and cost effectiveness, provides sparks for innovation in both the public and private sectors.
One major criticism in this paper of TCIP is that documentation on the standards development process and the standard itself is difficult to consume. As mentioned above, understanding the changes between versions of the standard is difficult because there is no list of versions and their respective changes over time. If this is difficult for the researcher, it is almost certainly difficult for any organization interested in implementing the standard. Therefore, another recommendation that follows the aim of transparency from the open data executive order is to substantially reorganize this content to improve not only the comprehensibility of the information therein, but also to simply improve the transparency of the project generally.
Predictions for Continued Trends
Based on the historical success of GTFS and the indirect network effects that bundle the static specification with its real-time component, there will likely be widespread adoption of GTFS-realtime in the near future. The 2013 survey on real-time arrival information by APTA (78) and TCRP Synthesis 104 on electronic signage by
88

Schweiger (69) mentioned above both capture a great deal of valuable information about the current market for real-time information.
One point drawn from the market analysis provided by the APTA survey is that there is immense demand by agencies to share real-time passenger information with their customers. Currently, only 37% of agencies are providing real-time information via an API or web or mobile application. For agencies without AVL systems, the vast majority of them (92%) are interested in installing AVL on their vehicles. Even of those agencies that have AVL systems already, 47% currently do not provide customer-facing real-time arrival times.
The benefits of public-facing (especially mobile) information systems have been well established (see Chapter 1), so it is likely that the agencies with AVL but without publicfacing systems will soon move forward with a public-facing solution. In fact, Figure 10 shows the reasons agencies are not providing arrival times to the public. While 8% of these agencies have projects in progress and a handful of others have organizational or technical restrictions, over 20% simply are constrained by technical ability or funding constraints. As open standards diffuse into the market, economic theory dictates that the cost of implementation will decrease, making feasible solutions a realistic option for more and more agencies.
89

Figure 10: Reasons given by transit agencies for not providing public arrival times (78)
By cross-referencing data sources that capture the usage of real-time transit passenger information standards, it appears that SIRI, GTFS-realtime, and TCIP all have a similar number of implementations in the U.S. However, the adoption rate for GTFS-realtime far outpaces that of either SIRI or TCIP (and even beyond that of NextBus, a popular proprietary solution). Anecdotal evidence from open source repository hosting applications such as GitHub (https://github.com) suggest that software development is most active around GTFS-realtime. While this should not serve as concrete evidence of adoption or even transit agency interest, it does bring up the question of how open movements (open standards, open data, and open source) overlap and reinforce one another and how this might apply to the case of real-time transit passenger information.
Federal Policy Recommendations
To date, there has been little visible response from the federal government to the development of alternative de facto standards for passenger information such as GTFS and GTFS-realtime. True, GTFS was incorporated into TCIP in version 3.0.5.2 of the
90

standard that was issued on March 1, 2012. However, it is unclear how effective the inclusion of this GTFS timetable importer has been for the proliferation of TCIP and, consequently, how effective such action would be for including translators or importers between GTFS-realtime and TCIP or SIRI and TCIP. It seems that the federal government could take one of a few alternative paths of engagement to respond to the likely proliferation of GTFS-realtime or the possible proliferation of SIRI in the United States. The paths listed here are as follows:
1. Achieve Interoperability work to develop translators or importers for de facto standards to keep TCIP relevant (as with static GTFS). In 2012, APTA released a new version of TCIP that included the functionality to import static GTFS "timetables" into TCIP-formatted messages. This could be an approach for keeping TCIP interoperable with real-time passenger information provided by agencies with GTFS-realtime, SIRI, or any other open standard.
This path is not recommended by this researcher because the cost of the approach is shouldered by the public sector rather than developers or vendors that otherwise might be incentivized to shoulder the development work themselves.
2. Provide Guidance to or Incent Vendors/Agencies shift focus to providing guidance on the development of open systems and use of open standards where realtime passenger information is concerned. Incentivizing vendors or agencies to provide open standards is listed as one of the FTA strategies to study in a 2011 FTA report prepared by the Volpe Center (11). The status of this program is currently unknown. However, the approach listed in this document promoted incentivizing only the adoption of TCIP. A more flexible approach would be to incentivize the adoption of any one of a set of open standards (perhaps any one of the three standards studied in this research). Such an action would (a) encourage a flexibility of approaches that would all be open, (b) allow market forces to shape an efficient outcome, and (c) possibly spur the market
91

of vendors or civic hackers to further develop translator/repeater to convert from one standard to the next.
This path is recommended because it draws a balance between cost effectiveness and ensuring the promulgation and (possibly) eventual interoperability of all open standards concerned. In this approach, there may be costs involved with incentives provided (whether they be financial or not), but these costs are likely to be less than Approach 1 and have the added benefit of engaging all stakeholders actively. Additionally, this path provides opportunities for the TCIP standard to be adopted for other functional areas within transit agencies. If GTFS-realtime in fact becomes a de facto standard for real-time passenger information (just as GTFS has already become), agencies may find greater benefit in TCIP if the standard is compatible with GTFSrealtime.
Follow Existing Path (Do Nothing) do not respond to the high adoption of realtime passenger information standards; let the market manage the adoption of standards and rely on regional ITS architectures to guide this process. This path is not recommended because it ignores the clear response of agencies to adopt open standards, whether TCIP or not. This policy response does not work to affect change or assist agencies or vendors that are interested in supporting open standards and, in turn, promoting the goals of regional ITS architectures to intra- and inter-agency interoperability as well as interoperability with emerging technologies and systems.
Conclusions
This research has addressed the history and background of federal ITS policy and the role of real-time transit passenger information. A comprehensive literature review of standard setting theory has helped to frame the multiple case study approach to understanding and reviewing the standard development processes for and institutional
92

influences on GTFS-realtime, TCIP, and SIRI--the major open standards used in the U.S. for the delivery of real-time transit passenger information. Among the impacts analyzed here are the effect that the standard development processes have had on the adoption and diffusion of the standards, or the "success" of each standard. Federal policy recommendations on the role of government in this area of growing importance are provided here as well.
Key Findings
A crucial finding of this research is that standards that open themselves to participatory and democratic processes (characterized by clear documentation, open communication--e.g. via mailing list--and rough consensus) may begin to play a larger role in technology and society. This has been demonstrated by Krechmer and others (24, 25) with the influential role that Internet Engineering Task Force (IETF) has played in building standards for the Internet--a process which is not without criticism or issues of its own (80)--one of the most important technology systems for today's economy and society.
These case studies also suggest that early, on-the-ground implementations of standards are critical to achieving adoption. Much like IETF, GTFS-realtime began as an invitation-only group in order to get rough installations of the standard implemented and working before opening the standard to the general public. This model is unable to account for the complex and comprehensive standards that may result from committee, but perhaps the committee approach is not always the most effective way to see standardization occur in an industry--unless broad consensus is met on implementation of the standard as with HDTV in the U.S.
As a strategy to achieve interoperability in this important area of transit ITS, the researcher recommends an incentive strategy for the federal government to promulgate
93

open standards for real-time transit passenger information. By incenting vendors and agencies to adopt any open standard (not just TCIP), the FTA would (a) encourage a flexibility of approaches that would all be open, (b) allow market forces to shape an efficient outcome, and (c) possibly spur the market of vendors or civic hackers to further develop translator/repeater to convert from one standard to the next. Such an approach would be cost-effective, engage the broadening base of stakeholders, and embrace the language supporting open and machine-readable government information in President Obama's Executive Order 13642. Future Work
Future work should include a comprehensive and systematic survey of transit operators, vendors, and the emerging group of contributors to transit web and mobile information systems. In addition to confirming the exact interfaces and standards implemented (in past surveys, responses sometimes indicate contradictory or confusing results), the survey should quantify perceptions and attitudes about open and proprietary standards. Commendably, APTA has begun to do this with their 2013 survey (see Figure 11), yet a cross-sectional look at not just agencies, but also vendors and other contributors, will help to clarify a complete vision of the state of standards development and adoption for real-time transit passenger information.
94

Figure 11: Issues agencies have with adoption of open standards for real-time data (78)
This proposed survey could tap the members of mailing lists maintained on Google Groups dedicated to the discussion of these specific standards (such groups currently exist for GTFS-realtime and SIRI) and the development of transit applications generally. It would be instructive, too, to revisit the vendor perspectives on open standards explored by Hickman in 1998 (38). While this research considered only APTA member transit agencies, expanding the scope to all transit operators in the region (including small circulators and university systems) would help to clarify the overall picture of perspectives on open standards.
Another future research area that may already be underway at FTA is to understand what kind of incentive structure would best spur agencies and vendors to adopt open standards. Currently, the research scope for agency and vendor incentives at FTA only allows for TCIP; however, it is crucial that other open standards for real-time transit passenger information be recognized as an integral pieces to a larger puzzle. The
95

comprehensive survey work described above would help to clarify the type of incentives needed to move the industry toward open standards.
While such research would be valuable to understanding motives and market forces currently in play, the next few years of standardization may obviate the need for such research. As open standards spread in the United States and the demand for real-time transit passenger information grows stronger, the industry may reach the tipping point of de facto standardization, enabling an efficient and effective marketplace for both purchasers and suppliers of real-time systems. The adoption of a standard by an industry and even a single agency is a complex phenomenon, full of many difficult to measure externalities. However, the open standards marketplace and the standards themselves can be made more efficient and effective through greater transparency and the further democratization of the standards development process.
96

Chapter 4: Traffic Management Centers and Third-Party Data
(James Wong, Bingling Zhang, Dr. Kari Watkins, and Dr. Hans Klein)
Literature Review
Traffic Engineering
Traffic Flow Fundamentals Traffic flow theory is largely described by what's known as the fundamental
equation, developed by Bruce Greenshields in the 1930's, which describes traffic speed on a facility as a function of that facility's density and carrying capacity. The image in Figure 12 shows three relationships between speed and density, speed and flow, and flow and density. The top-right quadrant describes traffic flow as a function of speed; as speed on a highway increases, more vehicles can travel on it (increasing flow), but at a certain point the number of vehicles exceeds the capacity of the highway, leading to congestion (decreasing flow). In the top-left quadrant, the relationship is between vehicle density and speed. As density increases and more vehicles are on a segment of highway, the speed that they will travel decreases. The third, and more abstract of the relationships, is in the bottom-left quadrant which shows that traffic flow and density are related in that increasing density will lead to increasing traffic flow, until a point where the density overwhelms the facility and traffic flow begins to decrease. Consider stopped, bumper-to-bumper traffic; density is very high, speed is very low, and traffic flow is nearly zero. On the other extreme, if only two cars are on a highway, they will travel with very fast speed, extremely low density, but similarly the flow is very little because there are so few vehicles.
97

Figure 12: Relationships among traffic speed, flow, and density (81) While the parameters that shape these relationships have been the subject of an
entire academic field, the fundamental relationship is foundational to the in-depth study of traffic flow.
Federal Legislation for ITS and Traffic Management
Federal policy and legislation have been important to the growth and development of traffic monitoring in its modern form. Traffic management centers and ITS infrastructure grew out of two decades of federal policy that supported Intelligent Transportation Systems (ITS), expanded real-time traveler information, and encouraged operational improvements in lieu of capacity-adding projects. This section includes some of the pertinent legislative elements that pertain to these policies.
In 2005, the United States passed the Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users (SAFETEA-LU). One of the programs listed under Congestion Relief was the Real-Time System Management Information Program. Under this program, the Federal Highway Administration (FHWA) would establish a system for all states to use that gave them the capability to monitor and
98

share real-time information on traffic and travel conditions for major highways in the country (82). The legislation outlined five specific conditions to monitor including road and lane closures, adverse weather conditions, congestion, travel times in congested metropolitan areas and transit service disruptions in metropolitan areas (83).
In November 2009, the U.S. Government Accountability Office (GAO) produced a report that described an evolving technological landscape for the collection and dissemination of real-time traffic information beyond traditional methods like inductive loop detection. The GAO found that the future of real-time traffic information relied on partnerships with the private sector (84).
The 2010 rule on the Real-Time System Management Information Program set 10 minute reporting standards for traffic incidents in metropolitan areas and 20-minute standards in non-metropolitan areas. For all information dissemination, the rule requires 85 percent accuracy with 90 percent availability; it specifically excludes any mention of coverage. The rule also allows for states to use funds to enter into agreements with private data collection companies to access and share real-time data (85).
The latest legislation, Moving Ahead for Progress in the 21st Century (MAP-21), was passed in June 2012 and represents a significant shift in federal policy towards performance management. That policy foundation is addressed with increased guidance for traffic congestion monitoring. Among the key elements that pertain to this discussion is language that gives US DOT the ability to address data standards: "the Secretary shall establish the data elements that are necessary to collect and maintain standardized data to carry out a performance-based approach." (86) During the current rule-making process, it is possible that the next federal rules would mandate certain data elements that necessarily require infrastructure-based traffic monitoring.
99

Brief History of Real-Time Traveler Information and Traffic Management Real-time traffic management has evolved rapidly over the past two decades.
According to an NCHRP report, traveler information was disseminated primarily through commercial television, radio broadcasts, and newspapers prior to the introduction of the internet in the mid-1990s; while changeable messages signs and highway advisory radio technologies were available, few were utilized. It goes on to say that the industry shifted dramatically when public agencies could provide traveler information using websites, which was both low cost and had the ability to reach a large audience. While television and radio remained primary sources of traveler information, the internet allowed for the development of real-time traveler information and traffic management technologies. With funding from the USDOT and the FCC designation of 511 as the national traveler information phone number, state DOTs have been successful in launching this system nationwide. Currently, real-time traveler information is also provided through dynamic message signs, navigation systems, and private sector applications (87).
Traffic Management Centers
Core Functions Traffic management centers (TMCs) are usually publicly operated facilities that
aggregate incoming data from traffic sensing equipment for a region and provide the foundation for traffic incident management. The core functions of TMCs typically include traffic incident management (TIM), traveler information and emergency operation management.
According to the 2010 Traffic Incident Management Handbook (88), the formalization of TIM began in the early 2000's and continues today. The motivation on the federal level is that congestion is considered an economic encumbrance, limiting the
100

ability for Americans to efficiently travel and adding to business costs. TIM is seen as an important method to mitigate congestion, in particular non-recurring events, which has economic benefits. The performance of a TIM program is measured based on roadway clearance time, incident clearance time and the number of secondary incidents incurred. All forms of TIM begin with some version of incident detection, notification and verification.(88) This is the first step in the process for most TIM strategies and is the primary function addressed by traffic monitoring equipment and ITS. Traffic managers are largely looking for anomalies in expected traffic patterns, for example, a slow-down in traffic on a segment of freeway with no entry/exit ramps. By identifying changes in speed, operators or algorithms can see where potential incidents are occurring that would then require verification.
Data Requirements
While the TIM Handbook is a guidance document shared and used by many agencies, it only picks up with instructions for responding to incidents; it makes no specific mention about best practices in incident notification.
In a 2007 study on the effectiveness of automated incident detection, researchers found that the technology is still in its early stages and unreliable for exclusive use. In that study, they found that almost all of the algorithms were based on relatively standard data sourced from various technologies: vehicle counts, average vehicle speed, and vehicle occupancy (which is a proxy for density). (89) Notably, the researchers predicted that since the technology had not yet been widely adopted and still had time for maturing, that "future detection systems should [be] designed to take advantage of vehicle-based sensors should such systems become widely available in the future." (89)
Many other studies and articles use the count-speed-occupancy dataset as the basis for traffic data collection and use (8993). The recent trend in research has been
101

to find alternative methods, technologically, to achieve speed data using probe-based vehicles. The authors are unaware of research articles that specifically discuss whether or not TIM, transportation planning or other traffic engineering tasks can be reasonably accomplished using only speed data.
The focus of this research has primarily been on operational use of traffic data, as opposed to its use for planning purposes. A review of traffic data users in 2002 found that "the most notable difference between operational and [planning uses] of traffic data is the emphasis on speeds and occupancies in the former and on volumes in the latter." (94) This is an important distinction, especially as it pertains to accuracy, because planning tasks often require single-deployment traffic studies where a 24 or 48-hour count provides the insight for as much as a year's worth of data; the review identified a +/- 10% accuracy (for volume) as sufficient for planning purposes based solely on the fact that temporal adjustments are made for data samples. The paper also admits that operations staff have limits on their need for accurate data: "In truth, the current generation of operational strategies do not require extremely accurate data operators typically need to know where the big problems are and their responses are geared to this."(94)
Existing Technology The vast majority of traffic sensing technology has been through the use of
infrastructure-based monitoring equipment in the field that communicates to a TMC or other central facility. These include loop detection, microwave radar, video detection and most recently, wireless in-ground sensors. Despite their varying technology, each of these is designed to provide operators with the count-speed-occupancy data described earlier.
102

The advances in technology and, more importantly, their broad deployment throughout major metropolitan areas have changed the way traffic incidents are detected. When describing the state of the practice in highway traffic operations and freeway management a decade ago, an author summarized as follows:
"The state-of-the-practice for electronic data collection is to measure traffic flow characteristics at discrete points throughout the network. Visual surveillance is typically performed via field-located cameras that are viewed by operators at a TMC. The most common method of detecting incidents is through motorists calling 911 or a specific call-in number set up for this purpose. Operators at a TMC generally use their traffic monitoring capabilities, especially visual surveillance, to verify incidents. Emergency responders, when on the scene, provide the best verification of incidents and the response needed." (95) In modern practice, agencies are far more reliant on use of speed maps with data generated either internally or externally to alert them to incidents that require attention. An important concept to understand is the difference between using infrastructure and probe-based sensing technology, particularly as it relates to the data output. "...Lagrangian sensing specifically refers to measurements performed along a sensor's trajectory, which it usually cannot control. Examples of this are smartphones traveling onboard cars to follow highway traffic flow. This is in contrast to Eulerian sensing, in which sensors are fixed (for example, video cameras or loop detectors along highways) and monitor a specific control volume in a static manner."(96) Eulerian data are ideal for reconstructing vehicle density in models because it is better equipped for a nearly complete penetration rate. Since the 1950s, this has been the primary mode of data collection and traffic-state modeling for transportation. Lagrangian data are starting to emerge in transportation, but only recently it has begun to see studies on the subject. The recent advances have been primarily in building a
103

probe system (96100), rather than focusing on data aggregation and applications. The key question that motivates much of this research is how the use of speed data alone impacts the effectiveness of TIM and operations.
Changes in Traffic Sensing Technology The technology behind probe-based systems has been developing rapidly over the
past few years. There are two primary methods that are used: one uses infrastructurebased readers to capture data on specific vehicles when they pass a point on a facility, the second reads the position of a mobile device wirelessly and aggregates that data to recreate a speed vector for a highway. The `position' of the mobile device may be generated using GPS-based systems, such as a navigation device, or it can also use cell-phone tower triangulation. The focus of this work is on GPS-based data from mobile devices.
Media Access Control (MAC) address matching can provide useful traveler information at a low cost. There exist some technologies, such as Bluetooth devices, have a specific MAC address, which can be detected by Bluetooth stations along a corridor; travel time can be determined by calculating the time it takes two separate Bluetooth stations to detect a specific MAC address. Schneider recommends that Bluetooth stations should be located one to two miles apart to optimize the amount of MAC address matches; the MAC address must be detected by at least two Bluetooth stations to provide a travel time (101). While Bluetooth signals do not require a line of sight, the signal may be negatively impacted by physical barriers and other devices, such as cordless phones and microwave ovens (102). However, since Bluetooth travel times are calculated between two Bluetooth stations, it is difficult to reconstruct speeds at specific points along a corridor.
104

The use of GPS technology in traffic management has the ability to exploit the accuracy in position and velocity of existing cellular networks which provide extensive coverage. One method of collecting traffic management data is using virtual trip lines geographic positions that indicate where GPS devices should provide updated locations (97, 103). In the Mobile Century field experiment, 2-3% of the total traffic flow contained vehicles equipped with GPS devices; the experiment indicated that traffic data obtained from GPS devices provided sufficient speed and position information (97). With the GPS system, transportation agencies have minimal installation or maintenance costs (97).
Networked Government
Networked government is the collaboration of government agencies with other public and private sector organizations in order to promote the public interest. In the United States, networked government has its roots in Franklin D. Roosevelt's New Deal in the twentieth century, expanding the government's influence (104). With World War II underway, the federal government began to enter in contractual relationships with military equipment vendors; this began the private sector influence on government policy. Networked government led to public-private partnerships that eventually led to the development of the space program, the interstate highway, Medicare, and Medicaid among others (104). The increasing demand for governmental services and decreasing desire for expanding the government has led to increasing connection with the private sector.
Networked government is common in the transportation industry. Agencies often work with the private sector to plan, design, and build transportation infrastructure. Traffic management centers purchasing third party data is an example of networked government, where the public and private sector collaborating to promote safer and more efficient transportation system for society.
105

Public Private Partnerships The growing popularity of public-private partnerships (PPPs) in the United States
has created an uncertainty in the definition of public-private partnership. Forrer (2010) offers the following definition:
"Public-private partnerships are ongoing agreements between government and private sector organizations in which the private organization participates in the decisionmaking and production of a public good or service that has traditionally been provided by the public sector and in which the private sector shares the risk of that production." (105)
Public-private partnerships are long term relationships between the public agency and one or more private organizations that are mutually advantageous and optimize on the strengths of each organization (105, 106). With a growing number of partnerships, accountability becomes ambiguous. Government agencies and private organizations often have different objectives when working on the same project; while the government agencies may be focused on promoting common good, the private organizations are often motivated by an increasing return on their investment (105). Unlike contractual relationships where accountability is often one-way, public-private partnerships require mutual two-sided accountability.
In the transportation industry, public-private partnerships occur frequently in financing and building toll roads. The private sector provides a financial commitment to building the facility and will ultimately share in the revenue streams, if successful, over a specified payback period. Obtaining third-party traffic management data can be described more accurately as a contractual relationship rather than a public-private partnership. The government is purchasing the data directly from a private sector vendor, with clear specifications as to the product being purchased. While this
106

relationship is long-term, the private sector does not participate in the decision-making process of the traffic management center and does not share any risk or profits.
Risk Assessment Utilizing third-party data changes the risk structure of the TMC. TMCs expose
themselves to risk when they are not self-contained; for example, TMCs cannot control the operations and maintenance of external power sources or leased communication fibers. In purchasing third-party data, TMCs experience additional external risk; TMCs cannot control the reliability and accuracy of the data. If third-party data were to completely replace infrastructure-based data, the TMC would be wholly dependent on the third-party to provide complete and accurate data.
Methodology
Researchers conducted a web-based survey to solicit responses from TMC managers around the United States. The TMC Manager title is loosely described in this research as an individual who has managerial or supervisory roles within a TMC or who plays a role in the planning and decision-making surrounding TMC facilities and operations. These individuals were assumed to have a working knowledge of the concepts discussed in the survey such as traf