Development of Transactional Data Specifications for Demand-Responsive Transportation (2020)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

59 This research focused on developing an implementable transactional data specification for demand-responsive transportation. The proposed specification—set forth in its entirety in Appendix E—is intended to be an initial step in enabling efficient data interoperability among the software systems used by DRT service providers. This would enable coordination for orga- nizations that want to share resources, carry more passengers, and be more cost-effective. But data interoperability is only likely to be feasible on a widespread basis if a common set of data specifications—such as those developed in this research—are available to be used by the interacting systems. Specifications-based transactional data interactions are commonplace in other transportation industries such as airlines, and have been well established for many years for DRT services in Sweden and Denmark. This concluding chapter has two purposes. First, a summary of the most important elements of this research is presented, highlighting the key findings and conclusions from the prior chapters. Second, we discuss the way forward—or more accurately, the possible ways forward— to actually implement a transactional data specification for the DRT industry so that the potential benefits of standardized data exchanges can be realized. 5.1 What Was Learned from the DRT Industry Advisory Panel A panel of 22 industry experts was formed to advise the development of the specification. This group, which included all of the key types of stakeholders discussed in Chapter 2, is referred to as the industry advisory panel. The research team engaged the advisory panel for two pri- mary purposes. In the early stages of the research, team members conducted semi-structured telephone interviews with industry advisory panel members to determine their perspectives on the importance of data specifications and how such specifications might come into being and be governed. Second, throughout the project, the industry advisory panel members took part in six virtual meetings, via conference call/web meeting, to provide input on the specification approach and the specifications themselves as they were developed. The detailed results of these two activities are presented in Appendix B. A list of the industry advisory panel members can be found in Appendix A. The industry advisory panel process resulted in four key findings. 1. There is general agreement with the objectives of a transactional data specification. 2. This is coupled with a high level of awareness of the multiple challenges that must be worked through if such a specification is to come into being on an industry scale. 3. There appears to be an absence of strong advocates within the DRT industry prepared to assume a leadership role in getting an adoption process under way—panel members liked Conclusions and Future Considerations C H A P T E R 5

60 Development of Transactional Data Specifications for Demand-Responsive Transportation the concept of specifications, but few seemed interested in taking a direct role in making specification implementation occur. 4. The development of a governance structure that can take ownership of the proposed specifi- cation is perceived to be a critically important need. 5.2 Key Lessons from Transportation-Related Examples of Data Specifications The case studies of the transportation-related data specifications revealed four important lessons concerning the objective of actual implementation of DRT specifications. First, Data Specifications Can Produce Game-Changing Results Transactional data specifications make possible not just data interoperability, but also business interoperability—organizations can readily concert their activities in ways that are mutually bene- ficial. The airline industry adopted this approach decades ago, setting in motion an evolutionary process involving specification-based data exchange for mutual business advantage that continues to this day. The SUTI standards are a major factor in the remarkable success of the FlexDanmark system. The FlexDanmark technology platform connects to several hundred organizations that sponsor and fund trips and more than 500 transportation service providers using many diverse technologies, all of which are SUTI-compliant, exchanging data with that platform and enabling it to manage DRT vehicle operations that collectively deliver up to 24,000 trips per day. Second, and Equally Important, the Ability to Achieve Specification Implementation Is Strongly Tied to Key Stakeholders Perceiving Financial Benefits or Other Direct, Concrete Benefits from Specification Adoption The actual implementation of the specification in organizations’ software systems requires the expenditure of resources, possibly significant resources. There is also substantial effort needed to enhance or simply maintain the specification. There must be a business reason for a specification for organizations to voluntarily agree to make such resource commitments. “Nice to have” will almost certainly not be adequate to convince organizations to adopt a specification. A business reason is clearly seen in the airline industry example, where the financial benefits of interlined ticketing were clear to all participants and resulted in the PNR specification for data exchange. Similarly, in the initial development of the SUTI standards there was a strong business reason—based on financial considerations—for the Swedish government to mandate a specification approach. The national transport ministry wished to ensure that the local public- sector organizations that received transportation funds would be able to procure technology systems that by design worked well together, avoiding the need for expensive custom integrations that would also result in vendor lock-in and lack of competition. While business reasons do exist for a DRT transactional data specification, they have not been clear to agencies funding a significant amount of DRT. Also, individual agencies that may understand the business reasons for using a specification do not have the power to effect change for the industry as a whole, for what is actually a national issue. Third, the Pace of Specification Development and Adoption Is Strongly Influenced by the Resources Under the Control of the Specification’s Proponents The contrast between how quickly GTFS came into widespread use once Google put its resources behind it, and the many-year process of developing GTFS-flex to a point where it

Conclusions and Future Considerations 61 might soon be adopted, is very telling. Google could devote substantial resources to an ambitious specifications development undertaking that in a relatively short period of time fundamentally changed how public transit data was structured and exchanged. In contrast, the developers of GTFS-flex have had limited and only episodic access to financial resources for developing specifications and promoting their adoption. Similarly, it has taken 9 years to move the Denver Trip Exchange—which includes DRT transactional data specifications—from concept to what is still only a partial reality, with comprehensive operations probably not occurring until late 2020. In both the GTFS-flex and Denver Trip Exchange cases the concepts for standardized data approaches made sense, but the proponents lacked the authority and financial resources to induce other key actors to make commitments that could have led to adoption in a few years. Fourth, Authoritative Actors, Whether They Are the Government or Private Companies that Are Major Players in an Industry or Sector, Make All the Difference in Achieving Specification Implementation While a voluntary, industry-initiated process is the most typical approach to specification development, an alternative pathway is for an organization with authority over industry partici- pants to mandate that specifications be adopted, as occurred with the Swedish government and SUTI standards. Market leaders do not have the same formal authority as governmental entities, but their ability to influence outcomes is similar. If an industry leader proposes technical speci- fications for how software systems interoperate, smaller competitors are likely to feel compelled to follow suit for fear of losing business otherwise. When FlexDanmark required all service pro- viders to adhere to the SUTI standards, its status as both a quasi-governmental actor and as the gateway to public-sector funding of DRT services in Denmark meant that technology companies and service providers had no alternative to specification adherence, if they wanted to be part of the DRT sector. Google’s promulgation of the GTFS specification and the fact that Google Transit—available only via Google Maps—would only work with this data meant that transit agencies were essentially forced to publish their data in this format if they wanted information about their services to be widely available. 5.3 Considerations in Developing the Specification The research team focused the core technical elements of the DRT transactional data specification on supporting the trip lifecycle. As described in Chapter 2, the trip lifecycle includes the following steps: 1. Trip reservation request—Focuses on customer logistics such as pickup and drop-off locations, requested pickup/drop-off times, and any relevant information about a passenger’s ambula- tory status. 2. Trip scheduling—Pertains to the assignment of a service provider and vehicle (or vehicle run) to the trip and determination of estimated pickup and drop-off times. 3. Trip cancellation—Optional step that occurs if the passenger cancels the trip request, including removing the assignment of transportation resources allocated to the trip. 4. Trip execution (delivery)—Includes actual deployment of the vehicle/driver to service the trip and the pickup and drop-off of the passenger to the destination, including fare payment when appropriate. 5. Trip reporting—Provides a full record of the trip from the request through trip delivery for data reporting and possible financial purposes. At this initial stage of specification development, sufficiency and simplicity are key to meeting the basic needs of DRT services for transactional purposes. The recommended specification ensures full coverage of the trip lifecycle, with a concise set of mandatory data elements and

62 Development of Transactional Data Specifications for Demand-Responsive Transportation a much larger set of optional data elements. This ensures that service and technology provid- ers will be capable of interoperating across the entire range of data and technology boundaries relevant to a DRT trip. The level of detail necessary for transactional purposes for any set of busi- ness relationships can be determined by the parties to the transaction; the specifications support both basic and detailed data exchanges. 5.4 Key Elements of the DRT Transactional Data Specification Two key elements of the proposed DRT transactional data specification are highlighted here. First, in recognition of the proven capabilities of the SUTI approach to DRT data specifications in Sweden and Denmark, this research has borrowed heavily from technical aspects of the SUTI standard. Most fundamentally, the proposed specification is based on the concept of telegrams, which is at the core of the SUTI approach. Telegrams consist of a specific message type that includes certain standard mandatory and optional data elements. The 11 telegrams proposed are intended to provide the essential data exchanges among software systems needed to support a DRT trip from end to end. Second, given the many potential participants in DRT transactions from an industry-scale perspective, the data communication approach underlying transactional data exchanges should also be standardized to ensure reliability. In particular, given the importance of specification validation during data exchanges, the research team concluded that an “internal translation with external validation” approach was most likely to be successful. Recommended Approach The recommended approach uses a control module that enables organizations sending and receiving messages to test their telegrams and ensure their mutual validity. In this approach, each technology provider is responsible for implementing a software system that produces specification-compliant telegrams. The providers are also responsible for ensuring that the messages sent and received are valid—the control module provides them with the ability to do that, but they must develop the software that interfaces with the control module for that purpose. To support this approach, the research team developed a basic software tool that can be used as an initial working version of the control module for validating that data are nominally compliant with the transactional data specification. This can be used by any software system needing to verify that its telegrams are syntactically correct. A description of this validation tool can be found in Appendix F. Alternate Approach If sufficient resources could be assembled, a translation broker approach would be pre- ferred, in which the broker software is responsible for ensuring that each message (telegram) is specification-compliant. After successful verification, the broker transmits the message to its recipient, which can be assured that it will process a specification-compliant message. This reduces the amount of work each DRT software system must do to ensure that transactional messages are specification-compliant. Unfortunately, the translation broker is a substantial software application that is likely to cost many tens of thousands of dollars (or more) to develop. It is not prudent to construct a specification approach on the assumption that the resources to develop this software will be available in the same time frame as specification implementation. If resources could be obtained to create the translation broker, this would be the recommended approach to data communication of the telegrams.

Conclusions and Future Considerations 63 5.5 Implementation—Potential Scenarios Developments in the DRT industry and advances in technology—with particular emphasis on the heightened importance of technology platforms—have created opportunities for improved DRT service outcomes if the software systems controlling these services can routinely inter- operate. The experiences in Sweden and Denmark offer evidence that such potential benefits are achievable, and transactional data specifications are a key element in making this possible. At the same time, it is clear from this research that developing a set of recommended specifications is necessary but not sufficient for achieving the desired objective. Success- ful implementations elsewhere have had consciously guided and organizationally supported implementation processes, with incentives to induce technology organizations in the DRT industry to adopt those specifications. In Sweden, the government was an authoritative advo- cate for SUTI transactional data specifications. In Denmark, FlexDanmark was a motivated market leader. Similarly, Google was motivated to develop GTFS because of potential business prospects. A core industry need does not exist in DRT as it does in the airline industry. While a transac- tional data specification would definitely produce benefits for some organizations that organize and fund DRT services—as the example of FlexDanmark makes clear—it is likely to be of limited value to others. Moreover, the industry advisory panel indicated no immediate prospects for leadership to arise from within the DRT industry. This means that another way forward is necessary if the benefits of transactional data specifications are to be brought to DRT industry participants in the near term. Rather than the typical top-down approach to specification development and implementation, bottom-up approaches are likely to be more promising, given current conditions. Multiple possible scenarios exist for advancing DRT transactional data specifications at the local, regional, or subindustry level. Local or regional initiatives may provide opportunities, as may well-funded pilot projects using federal, state, or regional funds. The Denver Trip Exchange is an example of how this could occur. The initial data specifications developed for that initiative have some similarities to those developed in this project, and it is conceivable that within the next year the Denver specifications could be superseded by the ones set forth in this report. The recommended data specifications and other technical outputs of the research presented in this report represent important technical and business resources that can be put to imme- diate use by those who perceive the importance of transactional interoperability among DRT technology systems. The specifications now exist, and are accompanied by a technically viable approach for data communication and specification validation. If the involved parties want to engage in interoperable/coordinated DRT transactions and choose to use the specifications developed in this project, they can do so by following the process set forth in Table 5-1. The approach presented can be quickly put in place if organizations are motivated to act. With the publication of this report and access to the included materials, such as the specifica- tion XML and the specification validation software tool to which there is a link in Appen- dix F, interested organizations now have the tools needed to make DRT service interoperability possible. What the tools cannot do is provide either the motivation to act or the institutional resources necessary to implement a process that results in transportation service providers and technology providers working together to implement and use the specifications for transactional purposes. To help motivated parties address institutional aspects in the near term, the research team developed communications-related items that may be useful for encouraging adoption and

64 Development of Transactional Data Specifications for Demand-Responsive Transportation implementation of the proposed specification. To help facilitate possible strategies, two docu- ments were created and included as appendices to this report: • Appendix G is a one-page marketing document that can be given to managers at transit agencies and/or other DRT service providers. Written in nontechnical language, it explains what a DRT data specification is and why DRT providers should adopt it. • Appendix H provides sample language that a transit agency or DRT service provider can include in an RFP that requires use of the transactional data specification. Over time, this bottom-up approach can lead to wider adoption across the transit industry and other DRT providers, as agencies take their lead from early adopters. However, in the longer term, a more formal approach to governance for managing and adapting the specification is needed. 5.6 Toward a Formal Governance Numerous potential organizing models for implementing and managing the transactional data specification were identified during the research. It is clear from the interviews and research that advocacy of the specification by one or more large organizations in this sector is important in catalyzing movement toward widespread, formal specification adoption. Table 5-2 sets forth eight governance models for the DRT specification, and Table 5-3 summarizes the strengths and weaknesses of each. • Model 1: Federal government mandates specification. Some interviewees suggested that the federal government might need to mandate a specification for it to be widely adopted. The agency that was mentioned by numerous interviewees was the FTA. Step Description 1 Organizations wishing to interchange data for transactional purposes determine which optional data elements need to be present in the messages that will be transmitted. 2 Each party’s technology provider makes changes to its software system so it can generate specification-compliant data messages to an external location. 3 Each technology provider establishes a connection to the external validator software and adds a protocol in its own system so that outbound and inbound transactional messages to/from other entities are validated before being transmitted or consumed. 4 The two (or more) organizations—and their technology systems—test transactional messages to determine if their data interchange is working properly. If problems are detected, they are fixed by the technology providers. 5 Organizations begin exchanging transactional messages, and new approaches to delivering service become feasible. Table 5-1. Steps to implementing the DRT specification. Number Description Model 1 Federal government mandates specification Model 2 International organization manages specification Model 3 One or more large local agencies agree on specification Model 4 Large company puts forth specification Model 5 Professional organization manages specification Model 6 University research center manages specification Model 7 Consortium of private-sector players agrees on specification Model 8 Develop and manage specification as open source project Table 5-2. Potential models for governance of the specification.

Conclusions and Future Considerations 65 • Model 2: International organization manages specification. Another suggested model was having an international organization or collaboration manage the data specification. One technology provider noted that many of its clients are international, and there would be benefits of coordinating this effort beyond the United States. • Model 3: One or more large local agencies agree on specification. Collaboration among a few large public agencies could result in a means of managing a future specification for DRT transac- tional data. A few large public agencies (e.g., New York, Los Angeles, and Chicago) could come together to make a standard happen; they could then release RFPs requiring that vendors use the standard. Or a few innovative transit agencies could work together and agree on a specification. • Model 4: Large company puts forth specification. The noteworthy example is Google and GTFS, in which a large company worked with a public agency to create a de facto standard. It is an open question, however, whether there is a company that is sufficiently large in the demand- responsive transportation industry to develop a standard and convince a large part of the market to adopt it. • Model 5: Professional organization manages specification. APTA or CTAA could be appropri- ate forums for managing a specification for transactional data. It is not clear whether either organization has sufficient technical expertise to play such a role. • Model 6: University research center manages specification. A university research center might play a central role in developing and maintaining a DRT data specification. The Center for Urban Transportation Research (CUTR) at the University of South Florida was cited as a possibility. However, this would likely require a dedicated funding source. • Model 7: Consortium of private-sector players agrees on specification. A possible model mentioned by several advisory panel members was a consortium of predominantly private- sector players. This could follow the model of the GTFS Best Practices Working Group that was recently convened; this effort was funded by the Rocky Mountain Institute, which encourages interoperable data standards. • Model 8: Develop and manage specification as open source project. The specification could become the focus of an open source project, as a stand-alone initiative or in combination with another model. Number Description Strength Potential Weakness Model 1 Federal government mandates specification Helps to encourage wide adoption of specification Concerns about government mandate Model 2 International organization manages specification Many software developers and operators are not U.S.-based Difficult to oversee and manage Model 3 One or more large local agencies agree on specification Specification based on actual needs and experience of local agencies Difficult to coordinate across independent cities and agencies Model 4 Large company puts forth specification Based on GTFS model for fixed-route service Difficult to identify analogous company in DRT Model 5 Professional/industry organization manages specification Known organizations that have created other industry specifications May not have needed technical expertise Model 6 University research center manages specification Nonpartisan and have technical expertise Would likely need ongoing funding source Model 7 Consortium of private- sector players agrees on specification Based on successful model of the GTFS Best Practices Working Group Would require high degree of initial and ongoing coordination among multiple parties Model 8 Develop and manage specification as open source project Technical advancements open to all able and interested groups Lack of coordination may lead to multiple specifications Table 5-3. Governance models with key strengths and weaknesses.

66 Development of Transactional Data Specifications for Demand-Responsive Transportation While authoritative government involvement in the specifications situation—Model 1— would almost certainly result in specification adoption, as was the case in Sweden, it is unlikely to occur in the United States. Rather, industry associations and the leading organizations in these industries are typically the key to successful development of technical specifications. These organizations can be private sector, public sector, research focused (including academic), or some combination. A key challenge is to find mechanisms and opportunities to engage these entities to help catalyze the development of a governance structure for the specification. Such a governance structure is likely to be the key to widespread adoption of transactional data specifications for DRT and ongoing evolution of such specifications, as has occurred in Europe with the SUTI standards. While this is clearly the desired end state of this specification development process, there are multiple challenges to its achievement. In the immediate term, a more productive focus may be on maximizing discrete opportunities to implement these or similar specifications in as many situations as possible when conditions are favorable. Nothing will be more important in building momentum for an industry-level approach to adoption and governance of specifications than a number of successful examples of their deployment and utilization in situations of a more limited scope.