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.

1 This report documents the development of a transactional data specification for demand-responsive transportation (DRT) (Box S-1). Transactional data contains all pertinent DRT trip details in a reservations scheduling and dispatching system, such as origin and destination of the traveler and time of the requested pickup or delivery. The transactional data specification is the set of rules that explain what data is needed, and in what format, for these trip requests and responses when the fulfillment of the trip involves at least two systems that must exchange data. A primary purpose of a transactional data specification is to enable DRT services in the United States to participate more fully and easily in an era of new mobility by facilitating interactions among the software systems that manage them. New mobility refers to a new generation of technology-enabled urban transportation ser- vices that includes bike sharing, car sharing, electric scooters, and on-demand transportation services operated by both private-sector and public-sector entities, including Uber and Lyft as well as public transit agencies. DRT, whose roots as shared-use public transportation extend back to dial-a-ride services beginning in the 1970s and continue operating in many communities today, encompasses these newer forms of on-demand service as well. DRT today includes comprehensive and fully automated technology plat- forms that manage service, smartphone apps for customers and drivers, Global Positioning System (GPS) tracking of vehicles, and digital data communications. Customers include the general public, older adults and young people lacking access to a vehicle, and individuals with disabilities. Why a Transactional Data Specification Is Needed Under current practice in the United States, each DRT reservations/scheduling software system is designed to meet the needs of the individual transportation service provider using that system. These software systems record trip characteristics in their own specific formats and have proprietary approaches to organizing and managing the trip lifecycle—consisting of trip booking, vehicle scheduling, service execution, and post-trip data reporting. These proprietary approaches prevent the routine exchange of trips among different transportation service providers with different software systems. S U M M A R Y Development of Transactional Data Specifications for Demand- Responsive Transportation Box S-1. Demand-Responsive Transportation Definition Demand-responsive transportation (DRT) services, sometimes referred to as on-demand services, are those in which a customer requests a trip from one specific location to another specific location that is then scheduled to a vehicle and dispatched. The vehicle does not travel on a fixed route nor follow a fixed schedule. DRT for public transportation purposes typically requires the vehicles providing the rides to be shared by unrelated parties, but for the purposes of this study DRT is defined more broadly and includes taxi and ride-hailing services.

2 Development of Transactional Data Specifications for Demand-Responsive Transportation The result: DRT services almost always operate in isolation from others in their proximity. This precludes the possibility of cross-system interactions that could reduce cost per passenger served and improve service quality. The ability to interact across the boundaries of services would produce benefits—fewer empty seats, lower cost per passenger, less delay for customers—to both passengers and transportation service providers, particularly the public and private nonprofit agencies that finance DRT services with public funds. In other transportation industries, the organizations that control the key software systems—or pay to use them—have developed transactional data specifications precisely to avoid the barriers to interoperability among systems. They have important business reasons to ensure that transactions can readily occur across organizational boundaries so the economic value of such transactions can be realized. For example, in the airline industry it is necessary for airline reservations systems to exchange data so that passengers can seamlessly make trips involving two or more airlines. Millions of airline trips every day make use of transactional data specifications initially developed several decades ago and evolved over time to handle increasingly complex data interchanges among industry participants. The airline industry could not exist in its current form without the data exchanges made possible by these specifications. In DRT itself, there is a precedent for transactional data specifications. The Swedish government initiated the development of DRT data specifications in the 1990s to enable local governments sponsoring DRT services to change software providers or transportation service providers—often large, regional scale taxi companies—without adverse consequence. As a result, the Standardiserat Utbyte av Trafik Information (SUTI, a Swedish acronym) standards, became mandatory for software and transportation service providers in Sweden and were eventually adopted by public agencies in the other Scandinavian countries. These agencies understood the benefits of imposing specifications that guaranteed the software systems of all DRT technology providers and transportation providers could interoperate. Vendor lock-in is avoided, trips could be allocated to multiple service providers, and service sponsors had more control over outcomes; the SUTI standards set the conditions for how technology worked, not the software vendors. Adherence to SUTI standards became the gateway to doing business in the DRT industry in Scandinavia. What a DRT Transactional Data Specification Encompasses A transactional data specification sets forth the vocabulary and syntax for how infor- mation about individual DRT trips can be transmitted from one computer system to another. This information includes the essential details about the traveler(s), the logistics of the trip, and any other information required to successfully order, schedule, and execute each trip. The recommended DRT transactional data specification spans the entire trip lifecycle, from the initial ordering of the trip to its execution and subsequent delivery of data to all relevant parties about how the service was performed (e.g., when the passenger was actually picked up and dropped off), all the way back to the entity that originated the trip order. This means that multiple organizations are able to participate in the trip ordering and delivery process with the assurance that each will have access to the complete set of data it needs to perform its specific function(s) properly. Every step in the process is recorded, and the data details are available—in a standardized data format—for subsequent reporting and analysis, including for financial transactions. In addition, the transactional data specifi- cation developed for this study includes a recommended data communication mechanism to

Summary 3 allow software systems from various service providers to exchange specification-compliant trip-related data. What Other Experiences with Data Specifications Teach Us Core principles for designing the transactional data specification—simplicity, sufficiency, flexibility, adaptability, compatibility, and technical appropriateness—were identified through research on data specifications for software system interactions in transportation and other industries, including directly relevant DRT situations. Five examples of specification- based common data formats in the transportation industry are identified in this report, with a short case study presented for each—the airline industry; the General Transit Feed Speci- fication (GTFS) for fixed-route transit; the GTFS-flex extension for flexible transit service; SUTI in Scandinavia; and a DRT trip exchange in the Denver region. The case studies of the transportation-related data specifications revealed four key lessons concerning implementation of DRT transactional data specifications. First, Data Specifications Truly Can Produce Game-Changing Results Transactional data specifications make possible not just data interoperability, but also business interoperability—organizations can concert their activities in mutually beneficial ways. The airline industry started down this pathway many decades ago with less than elegant technical approaches, but an evolutionary process involving specification-based data exchange for mutual business advantage was set in motion and continues to this day. Much can be learned from the situation in Scandinavia that is directly relevant to the focus of this study. Not only does the existence of SUTI standards make it clear that data specifications for DRT are both technically and operationally feasible, equally significant is the key role those specifications played in making possible the development of the remarkable FlexDanmark system in Denmark. FlexDanmark is likely the largest publicly supported DRT system in the world. In a country of 5.5 million people, it operates in each of Denmark’s six public transit regions, trans- porting up to 24,000 passengers per day—the general public, senior citizens, individuals with mobility limitations, people needing transportation for healthcare purposes, school- children with special needs, and others. It uses more than 500 different transportation service providers—taxi companies, medi-van operators, school bus companies, public transport contractors—that collectively operate more than 5,000 vehicles. Passenger trips are sponsored by more than 500 publicly funded agencies, including municipalities paying for trips for the general public, many healthcare organizations (including large hospitals and medical centers), and school districts, some of which enter orders for their clients directly into the FlexDanmark trip-booking system. All data communication between the ordering systems, the FlexDanmark scheduling system, and the transportation providers’ computer systems— including the devices used by their drivers in the vehicles—is accomplished with data messages based on the SUTI standards. Second, and Equally Important, the Ability to Achieve Specification Implementation Is Strongly Related to Key Stakeholders Perceiving Financial Benefits or Other Direct, Concrete Benefits from Specification Adoption Implementing a specification in organizations’ software systems requires the expendi- ture of resources and ongoing efforts to enhance or simply maintain the specification.

4 Development of Transactional Data Specifications for Demand-Responsive Transportation There must be a compelling business reason for organizations to agree voluntarily to make such commitments. “Nice to have” will almost certainly not be adequate motivation. A business reason is clearly seen in the airline industry example, where the financial benefits of interlined ticketing are clear to all participants and resulted in specifications for data exchange several decades ago that have been maintained and evolved ever since. In the case of the initial development of SUTI standards there was also a strong business reason based on financial considerations. The Swedish national transport ministry wished to ensure that local public-sector organizations to which it distributed transportation funds would be able to procure technology systems that by design worked well together, and would not need expensive custom integrations that would also result in vendor lock-in and lack of future competition. Third, the Pace of Specification Development and Adoption by an Industry or Sector Is Strongly Influenced by the Resources Under the Control of a Specification’s Proponents GTFS was adopted and disseminated and came into widespread use in several years once Google put its resources behind the specification. Google could devote substantial resources to an ambitious specification development undertaking that in a 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; this proposed extension is not yet formally adopted. 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 participants to mandate that specifications be adopted, as occurred with the Swedish govern- ment and the SUTI standards. Market leaders do not have the same formal authority as governmental entities, but if an industry leader proposes technical specifications, smaller competitors are likely to feel compelled to fall into line for fear of losing business. In Denmark, transportation service providers and technology companies were required to adhere to the SUTI standards if they wanted to be included in the FlexDanmark sys- tem. As that system became the gateway to most public-sector–funded DRT in Denmark, businesses had no practical alternative to adhering to the specification if they wanted to participate. Google’s promulgation of the GTFS specification and the fact that Google Transit 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. What We Learned from the Stakeholders in the U.S. DRT Industry To obtain input directly from individuals knowledgeable about DRT, the research team convened an advisory panel of 22 members representing DRT industry stakeholders: soft- ware companies and other technology providers; transportation service providers (public transit and healthcare/human services contractors, TNCs, taxi companies); public transpor- tation agencies; and researchers involved in data-related matters. The advisory panel served

Summary 5 as a key resource to the research team, meeting six times via conference calls. Structured interviews with panel members provided additional information on industry perspectives and objectives regarding transactional data specification. The advisory panel process resulted in several key findings. 1. There is general agreement among DRT industry stakeholders with the objectives of a transactional data specification. 2. There is an awareness among many stakeholders of the challenges that must be overcome if a specification is to achieve an industry scale, most importantly: – Lack of incentives to induce technology providers to standardize data formats and adopt a common data vocabulary for transactions; – Cost of switching to a data specification from current proprietary data approaches; and – Current absence of any governance structure to assume the leadership and direction of a specification development/implementation process. 3. There is a shortage of strong advocates within the DRT industry prepared to assume a leader- ship role in an adoption process. Advisory panel members liked the concept of transactional data specifications for DRT, but few seemed interested in taking a direct role in undertaking specification implementation. The advisory panel process, inputs from multiple other DRT industry sources, and the experience with successful specification development in other industries all point to the development of a governance structure led by a neutral, well-respected party that can take ownership of the proposed specification as critically important. The perspective of a key group of stakeholders, namely the agencies funding a significant amount of DRT service, also bears emphasis. The business reasons for a transactional data specification have not been clear to many in this group, even though they could be major beneficiaries. Moreover, those agencies that may understand the business reasons for adopting a data specification for DRT do not perceive that they have the power to effect change for what is a national issue. They view their agency as one of many buyers of DRT software, and typically do not believe that they have sufficient leverage or technical expertise to propose or impose nationally relevant specifications. What the Recommended Specification Makes Possible: Data Interoperability The core purpose of a transactional data specification is simple: to enable different computer software systems to interoperate to achieve some defined business and/or technical purpose. The specification that has been developed in this study accomplishes two objectives. • First, it establishes common language for entities to communicate transactional data with one another, to accomplish DRT trips from beginning to end of the trip lifecycle. • Second, it provides a recommended technical approach for how data communication would occur among the interoperating computer systems. The proposed specification is based on a telegram concept—the same used by the SUTI standard in Scandinavia. Telegrams consist of message types with specified data elements. Telegrams are sent from the computer system of one party to the computer system of another party to advance a transaction involving a passenger trip. All valid telegrams are composed of a predefined message type whose message contents must include all the data elements required for that type of message, and can include optional data elements.

6 Development of Transactional Data Specifications for Demand-Responsive Transportation The Way Forward: Next Steps to Implement a Specification This report concludes with a discussion of possible ways forward to implement a data specification in the U.S. DRT industry so the potential benefits of standardized data exchanges can be realized. The key challenges to moving forward quickly with industry- level adoption of a transactional data specification have been identified above. In consid- eration of those challenges, the study team has provided some key tools to support a more bottom-up approach to specification adoption, a strategy that may yield more near-term results, most likely at a regional or local level. Toward that end, we have provided documents that (1) make the case for why DRT transactional data specifications are important to improving the benefits from DRT services; and (2) can be used in requests for proposal by public agencies procuring technology or transportation services for DRT systems, to require that respondents be compliant with the proposed data specification. In addition, a transactional data specification validator software tool has been developed that can be used by software systems that want to implement the specification proposed in this report. The software tool verifies that the telegrams—data messages generated by a software system to communicate with another system—are specification-compliant. The website that hosts the data validation service is http://tcrp.demandtrans.com Public transportation agencies, DRT service providers, and technology providers can use the products of this report to move forward toward implementation—and operational use—of transactional data specifications in existing and new DRT services. The products are also available to other actors involved in new mobility, such as cities, planning agencies, and healthcare organizations, to support adopting transactional data specifications to foster the cost-effective evolution and growth of DRT services.