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.
7 Executive Summary This report documents the development of a transactional data specification for demand responsive transportation (DRT). 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 are needed, and in what format, for these trip requests and responses, when the fulfillment of the trip involves at least 2 systems that must exchange data. A primary purpose of a transactional data specification is to enable DRT services in the U.S. to more fully and easily participate 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 services that include 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 the Dial-A-Ride services that began in the 1970âs and continue to operate in many communities today, encompasses these newer forms of on-demand service as well. DRT today includes comprehensive and fully automated technology platforms that manage service, smartphone apps for customers and drivers, 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 U.S., 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. The result: DRT services almost always operate in isolation from others in their proximity. This precludesâtodayâthe possibility of cross-system interactions that could reduce cost per passenger served and improve service quality. On the other hand, being able 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 non-profit agencies that finance DRT services with public funds. Demand responsive transportation 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 un- related parties, but for the purposes of this study DRT is defined more broadly and includes taxi and ride- hailing services.
8 In other transportation industries, the organizations that control the key software systemsâor who pay to use themâhave developed transactional data specifications precisely to avoid the barriers to inter-operability among systems. They have important business reasons to ensure that transactions can readily occur across organizational boundaries so that the economic value of such transactions can be realized. For example, in the airline industry it is a necessity for airline reservations systems to be able to exchange data so that airline 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. In Scandinavia, the Swedish national government initiated the development of DRT data specifications in the 1990âs in order to enable local governments who sponsored DRT services to be able to change software providers or transportation service providersâoften large, regional scale taxi companiesâwithout adverse consequence. The result, the so-called 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 that the software systems of all DRT technology providers and transportation providers could inter-operate. 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 the 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 information 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 and 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 the 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 that they need to perform their specific function(s) properly. Every step in the process will be recorded and the data details will be availableâin a standardized data formatâfor subsequent reporting and analysis, including for financial transactions. In addition, the transactional data specification developed for this study includes a recommended data communication mechanism to allow software systems from various service providers to actually accomplish the of exchange specification-compliant trip-related data.
9 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 the report, with a short case study presented for each: the airline industry, the General Transit Feed Specification (GTFS) for fixed-route transit, the GTFS-Flex extension for flexible transit services, 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 vis-Ã - vis the objective of actual implementation of DRT transactional data specifications. First, data specifications truly can produce game changing results. Transactional data specifications make possible not just data inter-operability, but also âbusinessâ inter-operabilityâorganizations can readily concert their activities in ways that are mutually beneficial. 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 that 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 the 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 operated in each of Denmarkâs 6 public transit regions, transporting up to 24,000 passengers per dayâthe general public, senior citizens, individuals with mobility limitations, people needing transportation for health care purposes, school children with special needs, and others. It uses over 500 different transportation service providersâtaxi companies, medi-van operators, school bus companies, public transport contractorsâwho collectively operate more than 5000 vehicles. Passenger trips are sponsored by over 500 publicly funded agenciesâ including municipalities paying for trips for the general public, many health care organizations (including large hospitals/medical centers), and school districtsâsome of whom 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 that are based on the SUTI standards. Second, and equally important, the ability to achieve specification implementation is strongly related to key stakeholders perceiving either financial benefits or other direct, concrete benefits from specification adoption.
10 The implementation of a specification in organizationsâ software systems requires the expenditure of resources and on-going efforts to enhance or simply maintain the specification; there must be a compelling business reason for organizations to voluntarily agree 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 inter-lined ticketing are clear to all participants and resulted in specifications for data exchange several decades ago, which have been maintained and evolved ever since. In the case of the initial development of the SUTI standards there was also a strong business reason based on financial considerations. The Swedish national transport ministry wished to ensure that the local public sector organizations to whom it distributed transportation funds would be able to procure technology systems that by design worked well together and were not subject to needing 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 the proponents of a specification. 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 specifications 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 who 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 government 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 otherwise. 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 system (described below). As that system became the gateway to most public sector funded DRT in Denmark, they had no practical alternative to specification adherence if they wanted to be participants. 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 In order to obtain input directly from individuals knowledgeable about DRT, the research team convened an Industry Advisory Panel comprised of 22 members representing DRT industry stakeholders: software companies and other technology providers, transportation service
11 providers (public transit and health care/human services contractors, TNCs, taxi companies), public transportation agencies, and researchers involved in data-related matters. The Advisory Panel served 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 vis-Ã -vis the 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 worked through if such a specification is to come into being on an industry scale, most importantly: â¢ A lack of incentives to induce technology providers to standardize data formats and adopt a common data âvocabularyâ for transactions. â¢ The cost of switching to a data specification from current proprietary data approaches. â¢ The 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 leadership role in getting an adoption process underway. Advisory Panel members liked the concept of transactional data specifications for DRT, but few seemed interested in taking a direct role in making specification implementation occur. 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 albeit well-respected party that can take ownership of the proposed specification to be a critically important need. 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 Inter-Operability The core purpose of a transactional data specification is simple: to enable different computer software systems to inter-operate 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 use to communicate transactional data with one another to accomplish DRT trips from the beginning to the end of the trip lifecycle. â¢ Second, it provides a recommended technical approach for how data communication will occur among the inter-operating computer systems.
12 The proposed specification is based on a âtelegramâ conceptâthe same as is 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 comprised of a pre- defined message type whose message contents must include all of the data elements required for that type of message, and can also include optional data elements. 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 DRT industry in the U.S. so that the potential benefits of standardized data exchanges can be realized. The key challenges to quickly moving forward with industry-level adoption of a transactional data specification have been identified above. In consideration of those challenges, the study team has provided some key tools to support a more âbottoms-upâ approach to specification adoption, a strategy that may be able to yield more near-term results, albeit most likely at a regional or local level. Towards that end, we have provided documents that: (1) make the case for why DRT transactional data specifications are important to improve the benefits from DRT services; (2) can be used in Request for Proposals by public agencies procuring technology or transportation services for DRT systems to require that respondents be compliant with the proposed data specifications. 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 intending to communicate with another system are specification-compliant. The website that hosts the data validation service is found at the following URL: http://tcrp.demandtrans.com Public transportation agencies, DRT service providers, and technology providers can use the products of this report to move forward towards implementationâand operational useâof transactional data specifications in existing and new DRT services. The products accessible via this report are also available to other actors involved in âNew Mobilityâ, such as cities, planning agencies, and health care organizations, to support the adoption of transactional data specifications as a means of fostering the cost-effective evolution and growth of DRT services.