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.

28 Companies and organizations in many industries use formal data specifications and data standards and commonly agreed upon data formats. This chapter presents five examples of data specifications and common data formats from the transportation industry. The first is from the airline industry. The second and third examples pertain to the General Transit Feed Specification (GTFS) that is commonly used to provide information about fixed-route transit services and a new extension for flexible transit services. The last two examples—one from the Denver region and another from Scandinavia—are most relevant to this project and present examples specific to demand-responsive transportation (DRT) transactional data. Each example includes a short technical description of the data format and a discussion of the process of developing the specification. The manner in which data is communicated— request/response, publish and subscribe, or API—is noted for each situation. These examples are explained in a nontechnical manner so they are accessible to those without significant information technology experience. The key difference in terminology between specification and standard, as initially described in Chapter 2, is important. Specifications are documented technical requirements generally considered working or business documents. Standards are documented technical requirements that have been agreed upon by consensus or established by a neutral third party. Some of the examples in this chapter, such as DRT data specifications in Scandinavia, involve formalized standards, whereas others focus on data specifications that are widely used but have not gone through a formal standard-setting process (e.g., GTFS). While all of these examples involve data specifications, not all involve transactional data—notably, the GTFS does not. 3.1 Example 1—Airline Reservation Data Specification (Request/Response) Despite being much larger in size than the DRT industry, the airline industry provides an example of data specifications for airline reservations that has many important similarities. Notable similarities include a market with multiple key players and differences in perspectives among key participants in how transactional data interoperability should best be achieved. Moreover, the airline industry has undergone huge technological evolution over the past 50 years that has challenged the approaches to transactional data specifications and data integration. Since the 1960s, the air travel industry has made use of a standardized means of structuring data about airline flights to enable computer reservations systems to share information about reservations and tickets. The need for data specifications arose due to interlining requirements, in which a passenger’s travel itinerary involved one or more airlines other than the airline that Examples of Transportation Industry Data Specifications C H A P T E R 3

Examples of Transportation Industry Data Specifications 29 the itinerary was booked on. There was a need to transmit the data for the flights on the other airline(s) to the computer reservation systems of those airlines, where a new record could be created in the other airline’s system that included data from the original booking record. This booking data could then be retrieved in the second airline’s computer system just as if the ticket had been originally booked on that airline. In response to this need, a detailed and comprehensive set of data message specifications was developed that focused on what is known as the passenger name record (PNR). These message specifications are managed by Airlines for America (A4A), the trade association for the U.S. airline industry, and the International Air Transport Association (IATA), the industry association for airlines worldwide. The data message specifications for PNRs are referred to as the ATA/IATA Reservations Interline Message Procedures—Passenger (AIRIMP). Somewhat surprisingly, there is no general industry standard for the layout and content of a PNR. Each airline reservation system, typically referred to as a computer reservation system (CRS), has its own proprietary standard for these messages. However, common industry needs, including the need to map PNR data easily to the messages, have resulted in many similarities in data content and format among all major airlines’ PNRs. Key PNR contents include • Record locator (identifier), a six-character value; • Name of the passenger; • Contact details for the travel agent or airline office; • Ticketing details, either a ticket number or ticketing time limit; • Itinerary of (at least) one segment, including origin and destination airports, airline, flight number; and • Name of person providing the information or making the booking. A PNR is created in an airline’s CRS when a passenger books an itinerary. The PNR is identi- fied by a record locator, an alphanumeric value consisting of six characters. If portions of the travel itinerary are to be provided by airlines other than the holder of the master PNR, then the PNR information is sent to the CRSs of the other airlines included in the booking. These other airline systems create copies of the master PNR in their own database—with a record locator specific to their own system—to manage the portion of the itinerary for which they are responsible. Many airlines have their CRS hosted by a third party, which allows easy sharing of PNRs. The record locator(s) of the copied PNRs are communicated back to the CRS that holds the master PNR, so all records will be tied together. This enables exchanging updates of the PNR when the status of the trip changes. For example, if the departure time of a connecting flight on another airline changes, this information will be sent to the master PNR of the originating airline. The PNR-focused system of data messages continues today and has been extended to hotel and rental car reservations booked in conjunction with airline travel. A substantial amount of optional data items not related to actual travel often need to be transmitted as part of the messages using the PNR framework. Consequently, the PNR system must be adaptable and flexible to handle optional data items that include: • Fare details and any restrictions that may apply to the ticket; • Tax amounts paid to the relevant authorities involved in the itinerary; • Form of payment used; • Frequent flyer data; and • Seat allocation. More recently, governments began requiring airlines to provide further information to assist investigators tracing criminals or terrorists, such as gender, passport information, and redress number, if applicable.

30 Development of Transactional Data Specifications for Demand-Responsive Transportation Changes to the data specifications system used by airlines are more complicated today because there are more players in the market than when the PNR system was developed over 50 years ago. While the record systems for airline reservations and PNRs remain proprietary, many other organizations, including online travel agencies such as Expedia or Orbitz, now handle PNR data and need access to airline data to provide consumers with information. Despite the advent of the online travel agencies, with much more modern computer tech- nology and data systems, the long-standing PNR system is still a core component of the data specifications used by the industry. There is an entrenched set of systems organized around this legacy data specification that are difficult to change. One example of a proposed modification to this data system includes the recent changes in airline pricing practices, most notably the “unbundling” of fares so that specific services (e.g., preferred seats, early boarding, checked bags) can be added to the ticket price. The current PNR system does not have the ability to handle these newer forms of pricing tickets that separate prices for specific services rather than charging a single price for the ticket and seat. Other initiatives—brought together and formalized under IATA, the governance body for the PNR specification—have extended specifications to these areas. This demonstrates the importance of a formal means to achieve consensus on key transactional data specifications over time as changes occur. Figure 3-1 summarizes important aspects of the airline reservation data specification. 3.2 Example 2—General Transit Feed Specification for Fixed-Route Transit (Publish and Subscribe) This example is from fixed-route transit services, and the data specification is known as the General Transit Feed Specification (GTFS). GTFS describes fixed-route transit service schedules and stop locations. There is also an extension of the specification named GTFS-Real Time CASE STUDY Airline Reservation Data Specification Who? International Air Transport Association (IATA) and Airlines for America (A4A), which are trade organizations for the airlines What? Data about individual passenger itineraries (e.g., flight number, origin airport, destination airport) Why? Passengers can travel on more than one airline in an itinerary, so data needs to be shared between airlines. How? Passenger name record (PNR) Lessons Learned The “golden rule”: those who have the gold (money) set the rules. Those who managed airline ticket transactions in their own computer systems, either major airlines or global distribution systems, were the impetus behind the PNR system, not technology companies. Governance Structure for Data Standards IATA publishes and maintains PNR data specification document and coordinates additional data specification initiatives. Figure 3-1. Summary of airline PNR example.

Examples of Transportation Industry Data Specifications 31 that enables transit organizations to publish the real-time location of their vehicles and their schedule adherence on the web. The example here is focused on the core GTFS system. This specification was established by Google in partnership with Portland, Oregon’s public transit agency, the Tri-County Metropolitan Transportation District of Oregon (TriMet). Google and TriMet worked together to create a data specification so that transit stop and schedule information could be presented in Google Maps using the trip-planning feature Google Transit. This collaboration resulted in the Google Transit Feed Specification. In 2005, TriMet became the first transit agency to publish its data in GTFS format. Since then, hundreds of transit agencies have published their fixed-route transit information in this format, and their data has been integrated into Google Transit, such as the example of Chicago shown in Figure 3-2. Subsequently, the Google Transit Feed Specification was renamed the General Transit Feed Specification, and it is maintained now by a community of transit agencies, software developers, transit planners, and other stakeholders. This specification is not set in stone; the community that maintains it can make proposals to extend the specification to enable new functionality, and changes do occur somewhat regularly. GTFS datasets are composed of a series of comma-separated value (CSV) tables in text format collected in a ZIP file. Six mandatory tables and seven optional files contain particular aspects of a transit service, such as routes, trips made by vehicles along a route, and stops along a route. The six required files (agency, routes, trips, stops, stop times, and calendar) are shown in Figure 3-3, which includes a brief description of each. Typically, each transit agency or operator creates its own GTFS feed, which is usually updated whenever the transit agency changes its schedule (generally three or four times per year). These Figure 3-2. Google Transit interface, which relies on GTFS data.

32 Development of Transactional Data Specifications for Demand-Responsive Transportation static GTFS feeds are then provided directly to Google for use in Google Maps. GTFS datasets are often made public by transit agencies and can usually be downloaded from the internet free of charge. Because GTFS datasets are easily available, they can be used by any organization with appropriate technical resources and capabilities. As a result, public transportation organizations that conform to the GTFS format often find that third-party technology providers make use of that data as a core element of consumer-facing software applications (or “apps”) that are of value to potential and existing riders of the transit system. GTFS can be used in applications such as Google Transit to convey different possibilities for fixed-route transit trips to passengers. Because it simply describes transit services to potential passengers, it is referred to as discovery data. Discovery data is information about what services exist, their configuration, and possibly their current status, for example, “The next bus on Route 12 arrives at Elm Street at 9:35 AM.” In contrast, transactional data includes all the information travelers need to actually book and schedule a specific trip, including payment information. These differences are discussed in more detail in the next case study on an extension of GTFS for flexible services, which include DRT. The GTFS example is summarized in Figure 3-4. agency.txt • Provides information about the transit agency, such as name, website, and contact information calendar.txt • Provides dates for service types (typically using a weekly schedule) stops.txt • Provides locations of stops along a route stop_times.txt • Provides times that a vehicle arrives at each stop along a route routes.txt • Provides information about distinct routes, such as route ID and route name trips.txt • Provides information about each trip along a route, including a trip ID and corresponding route ID ZIP GTFS Figure 3-3. Mandatory GTFS content. CASE STUDY Fixed Route Transit Information in the General Transit Feed Specification (GTFS) Who? Google and TriMet (Portland's transit agency) What? Fixed route transit stop and schedule information Why? To integrate transit trip planning, maps, and schedule information into software applications, such as Google Transit How? General Transit Feed Specification (originally known as the Google Transit Feed Specification) Lessons Learned Openly published data in a common format has resulted in many third-party apps that benefit transit riders. Governance Structure Google-organized interest groups oversee specification process; ultimate authority resides with Google. Figure 3-4. Summary of GTFS example.

Examples of Transportation Industry Data Specifications 33 3.3 Example 3—General Transit Feed Specification for Flexible Transit (Publish and Subscribe) This example is an in-progress, proposed extension of GTFS known as the General Transit Feed Specification for Flexible Transit. GTFS-flex accommodates certain forms of demand- responsive transportation services, demonstrating that specifications are not static, but continue to evolve. GTFS-flex will transmit some information (e.g., eligibility requirements) that could interface with DRT transactional specifications in the future. It is an example of how a specifica- tion can be changed and the challenges in doing so. The intent of GTFS-flex is to allow any non–fixed-route transit service to be described precisely in terms of its service characteristics, location and methods of customer access, and temporal availability. This can include traditional address-to-address DRT services as well as variants such as checkpoint DRT (in which passengers access the service only at designated points), route deviation service, and any other transit-like service with flexible elements that enables the path of the vehicle—and potentially its schedule—to be determined at least in part by customer requests. While this proposed extension of GTFS is specific to DRT and other flexible services, it is restricted to discovery data and does not include transactional data. Typically, GTFS-flex data would be used by a prospective traveler who enters their origin and destination in a trip-planning application; the system then informs them of services that are available and where and how they can be accessed. It would provide the customer with the service’s operating hours, where pickup points are located if only discrete locations are served, and a telephone number or website URL so that a trip could actually be booked. But GTFS-flex only provides basic information and cannot tell the customer if they can actually schedule their trip because it has no access to transactional data, such as where vehicles are currently located or vehicle availability for a specific time or from a specific origin. GTFS-flex proposes a few noteworthy changes to the original GTFS format to accommodate demand-responsive and flexible transit services. GTFS-flex introduces a new file known as “area.txt,” which accommodates the fact that many DRT services operate within a specific geographic area. In addition, three of the mandatory files (stop_times, routes, and trips) from the original GTFS format are modified to accommodate various types of DRT services (see Figure 3-5). For example, some DRT services can be organized as checkpoint services or have point deviations, which occur when vehicles serve demand-responsive requests at specific stops (there could be many) within a zone without any regular path between stops. This is accom- modated by changing the structure of the “stop_times.txt” file, which previously required stops to be served in a specific order. Similarly, a form of DRT service is based on route deviations, in which vehicles operating on a regular schedule with defined stops and an implicit path stop_times.txt •Numerous modifications, including accommodating point and route deviations routes.txt •Additional field to accommodate eligibility requirements of DRT riders trips.txt •Numerous added fields to define service parameters, such as maximum travel time Figure 3-5. Examples of changes to mandatory GTFS files in GTFS-flex.

34 Development of Transactional Data Specifications for Demand-Responsive Transportation will deviate to serve on-demand requests within a service zone encompassing the route. The information that defines the feasible deviations is also accommodated by a change in the “stop_times.txt” file. Two other noteworthy changes have been made. Many flexible transit services have service parameters for maximum or expected travel times, which are incorporated into the proposed GTFS-flex specification by additions to the “trips.txt” file. Additionally, some DRT services are only available to certain types of people (e.g., the elderly, Medicaid recipients); these eligibility requirements are accommodated in GTFS-flex by an additional field in the “route.txt” file. Additional modifications can be found in the proposed specification for GTFS-flex on GitHub at the following link: https://github.com/CUTR-at-USF/gtfs-flex/blob/master/spec/reference.md Some of the initial concepts for GTFS-flex were developed at a workshop called GTFS for the Rest of Us in November 2013. Since then, interested parties regularly communicate via a Google Group, and efforts are under way to try to formalize GTFS-flex. GTFS-flex is still in a prototype phase, which included a recent alpha launch on DRT services in the state of Vermont. The launch is being led by the Vermont Agency of Transportation (VTrans), Trillium Transit, and Cambridge Systematics, and it will demonstrate the capabilities of the proposed GTFS-flex extension for DRT discovery data. The transit agency in Denver intends to incorporate GTFS- flex into its trip-planning capabilities and has initiated the necessary process. To help manage extensions or changes to GTFS, a process is used to formalize proposed modifications or additions to the specification. One of the key hurdles to implementation of a proposed GTFS change or extension is that at least one GTFS producer (e.g., a transit agency) and one GTFS consumer (e.g., an app or web-based application) must have implemented the proposed change. In the case of GTFS-flex, the prototype release took place in Vermont and, for actual services, an implementation led by the large consulting firm Cambridge Systematics is committed to this new specification. Until GTFS-flex is officially implemented by the transit agency in Denver, there may not be any moves to seek formal inclusion of GTFS-flex in the official GTFS specifications. In fact, it remains unclear just how Google will handle the final steps of formally incorporating GTFS-flex into the GTFS specifications. This example demonstrates the challenges to both gaining transit agency support and achieving formal official status for new specifications merely for DRT dis- covery data; formal transactional data specification implementation would appear to be a larger challenge. The example of GTFS-flex is summarized in Figure 3-6. 3.4 Example 4—DRT Transactional Data in the Denver Trip Exchange Project (Hybrid of Request/Response, Publish and Subscribe, Open API) The Trip Exchange, a web-based system developed as part of an FTA-funded Mobility Services for All Americans (MSAA) project, is the next example. The origin of the Trip Exchange software (not the concept, which had been discussed in Denver since 2010) was an actual implementa- tion developed for Ride Connections in Portland several years ago; for a variety of reasons that software was not used for production purposes. Nonetheless, it provided a good real-life model for the functionalities and processes needed for a trip exchange system, and the Denver Trip Exchange follows its paradigm in many ways. At the same time, the core software developed for the Denver system is a completely separate implementation (even a different programming language) whose features are not identical to that of the Ride Connections software (e.g., the latter did not use web-based APIs), and is designed for more fully automated processes.

Examples of Transportation Industry Data Specifications 35 The Trip Exchange software was implemented by late 2017 and is in the early stages of use by DRT providers in the northern Denver region. This encompasses an area extending from central Denver northward to Broomfield and Boulder counties, including the city of Longmont. The Trip Exchange enables multiple transportation providers—each with its own DRT software system for reservations, scheduling, and dispatching—to share data with other providers to enable transactions among them. Four DRT providers are involved in the project: • Denver’s regional public transit agency, the Regional Transportation District (RTD), which provides an extensive set of general public DRT services as well as ADA paratransit; • The City and County of Broomfield, which provides transportation to eligible community residents; • Two human services transportation providers: – Seniors’ Resource Center, the largest senior citizens program in the Denver area; this orga- nization mostly provides service to its own clientele. – Via Mobility Services, a large human service transportation operator focused on providing DRT services under contract to public and private nonprofit agencies; also a major con- tractor for the RTD’s general public DRT program (note that this is not Via, the shared-ride van TNC company that operates in several U.S. cities). Two technology companies are also involved in the project: DemandTrans Solutions and RouteMatch Software. The organizations are summarized in Table 3-1. The Trip Exchange works as follows: 1. The DRT providers—and soon other human service organizations that need transportation for their clients—submit customer trip requests in the form of electronic trip tickets. These trip tickets specify when and where the customer needs to travel and any special needs— such as wheelchair accommodation or an accompanying escort or service animal—of the traveler. 2. Providers are able to offer their services for unmet customer travel needs of other providers by claiming trip tickets. CASE STUDY Who? GTFS curators, Vermont Agency of Transportation, Trillium, Cambridge Systematics What? Demand-responsive/flexible services descriptive data for trip planners Why? To extend scope of GTFS to non–fixed route services How? GTFS-flex proposed extension to GTFS Lessons Learned Creating specifications is easier than achieving their real-world implementation; transit agencies are key to supporting implementation. Governance Structure Same as for GTFS, Google as curator plus advisory group General Transit Feed Specification for Flexible Transit (GTFS-flex) Figure 3-6. Summary of GTFS-flex example.

36 Development of Transactional Data Specifications for Demand-Responsive Transportation 3. The Trip Exchange identifies potential matches between providers with capacity and unmet customer travel needs based on the following: date and time of trips, location of providers and trip makers, mobility requirements, and service eligibility. 4. When a provider is capable of fulfilling a trip ticket submitted by another provider, the Trip Exchange makes that trip ticket visible to the potential claimant and activates the functionality that enables it to claim the ticket. 5. The claiming process can be either manual on the website—a user interface enables providers to see all unclaimed trips relevant to them and determine if they wish to claim any of them— or automated, in which the computer system of the provider is directly responsible for claiming trips. In the case of automated claiming, the provider’s computer system will use the data on the trip ticket to first determine if the trip will fit into the provider’s vehicle schedule for the date and time of the trip, and only claim trips that do so. 6. If the trip is actually delivered (it is possible that the trip request will be cancelled by the trip maker in the originating provider’s system, in which case it notifies the Trip Exchange which, in turn, invalidates the trip ticket) the trip provider (claimant) sends the trip execution data results back to the Trip Exchange shortly after trip execution. 7. When the trip has been delivered, the Trip Exchange sends the trip execution results back to the entity that submitted the trip ticket. Members of the Trip Exchange will see the status of their clients’ trips move from Posted to Claimed to Executed. DRT service providers can interact with the Trip Exchange system in two ways: 1. Providers can log on to the Trip Exchange and use its functionality—available via a web browser—to perform a variety of actions, including claiming trips. 2. Providers can set up automated machine-to-machine communication between their software system and the Trip Exchange to post trip tickets and claim trip tickets based on available capacity on their service and established relationships among “trusted partners”—those that have previously agreed to transport each other’s clients on a routine basis without trip-by-trip approval. Each provider can program its own system to claim trips based on criteria specific to its mission and operating objectives. The Trip Exchange merely executes its requests. The Trip Exchange hub is designed to work with any external software system through application programming interface (API) connections. An API is a software module that enables one computer system to interact and exchange data with another computer system; the two systems can be anywhere as long as they can connect via the internet. The Trip Exchange hub transfers information among its participants through structured messages that include only the minimum amount of information needed for a provider to decide if it is able to accept the trip and fulfill its requirements. The messages are designed to include PARTNER ROLE Via Mobility Services Mission is providing specialized transportation in Boulder County. Also operates RTD-contracted DRT services. Denver RTD Regional transit operator; provides DRT services to general public and persons with disabilities (separate services). Broomfield–Easy Rides Mission is providing demand response service to the elderly and disabled in the City and County of Broomfield. Seniors’ Resource Center (SRC) Mission is specialized transportation in Jefferson County and the northwest metro area. DemandTrans Solutions Develops Trip Exchange hub; interfaces its DRT technology platform (for RTD DRT services) to Trip Exchange hub. RouteMatch Adapts RouteMatch software, used by all providers other than RTD, to interface with Trip Exchange hub. Table 3-1. Parties involved in the Trip Exchange project.

Examples of Transportation Industry Data Specifications 37 all essential information that transportation providers need to make a decision about whether they can accommodate the trip, such as pickup and drop-off addresses, requested pickup time, whether the passenger is traveling with a mobility aid such as a wheelchair or walker, and whether they are traveling with companions or service animals. The Trip Exchange has its own data specifications. It requires participants’ software systems to communicate with the hub using a standardized set of messages with defined data elements. Some data elements are mandatory, and others are optional. The APIs of the Trip Exchange are designed to work with the data specifications, and the Trip Exchange documentation specifies the required data elements. Figure 3-7 shows schematically how the Trip Exchange hub works in its fully automated mode. The Trip Exchange is currently set up only with the basic functionality to exchange trip information and facilitate DRT transactions. In addition, several different reports can be run, such as a monthly report of trips delivered by provider. Enhancements are planned for 2020 (using funds from another federal transportation project obtained by the Denver region) to address billing and financial requirements and to provide more options for multilateral business relationships among participants. For example, when trips are claimed, the provider’s price to perform the trip will be calculated and presented to the agency that posted the trip, and the latter can decide whether to accept or decline the claim. An important characteristic of the Trip Exchange system is that it does not require a brokerage or centralized reservation system to determine if trips can be shared. Control over whether or not trips are posted and claimed resides with individual participating organizations. As such, it is designed for a decentralized system in which individual providers have their own methods of booking and scheduling trips. This means that the exchange allows human service transpor- tation providers to see trip requests (visually or via automated mechanisms) and determine if Figure 3-7. Denver Trip Exchange hub structure.

38 Development of Transactional Data Specifications for Demand-Responsive Transportation they can add a trip to an existing vehicle run, which is important given limited vehicular and driver resources. This supports the goal of providing more rides to more people using existing resources. While the Trip Exchange is still in its formative stages, it is operational and demonstrates that multiple interested and motivated parties can work together to develop a common plat- form to enable interoperability among DRT systems. The data specification developed for the Trip Exchange is fundamental to its workings and represents the result of a collaborative process involving many months of work by both technology-focused and operations-focused participants. While that specification is different from the one developed in this study, it also explicitly supports the trip lifecycle and transactional processes and shares some important commonalities about core messages and the data they need to contain. In addition, the Trip Exchange’s data communication paradigm—a hybrid of a published API to enable software systems to transmit data to and from the Exchange, a request/response mechanism to advance transactions, and a publish and subscribe mechanism to notify participants when new trips of potential interest are posted to the Exchange—illustrates the importance of the three data communication models as organizing concepts for enabling transactional data flows. With the current data foundations of the Trip Exchange in place, the organizations that participated in its creation, and others in the Denver region, are ready to move on to adding more functionality to the system, to build on what they perceive to be a solid platform for enabling transactions among the participating entities. The example of the Denver Trip Exchange is summarized in Figure 3-8. 3.5 Example 5—DRT Transactional Data Standards in Scandinavia (Request/Response) The final example is the Scandinavian standard for DRT transactional data, known as SUTI (Standardiserat Utbyte av Trafik Information). This is the only known widely used data specifi- cation for DRT, and therefore it is particularly relevant to this project. SUTI today is the standard CASE STUDY Who? Denver RTD, Via Mobility Services, Seniors' Resource Center, City of Broomfield, DemandTrans Solutions, RouteMatch What? Trip Exchange for transactional DRT trip coordination between organizations that need additional transportation services and those that can offer services Why? Coordination of transportation services to use resources more cost- effectively and expand service How? Building a trip exchange technology platform using data specifications Lessons Learned DRT service providers agreed on the design of a technology platform for transactional-based service coordination, which demonstrates that a trip exchange is feasible. Governance Structure Steering committee of agencies and companies who oversaw development of Trip Exchange Denver MSAA Trip Exchange Project Figure 3-8. Summary of the Denver Trip Exchange example.

Examples of Transportation Industry Data Specifications 39 throughout Sweden, Norway, Finland, and Denmark for the exchange of DRT information between providers (i.e., contracted vehicle operators) and their clients (i.e., the organizations responsible for DRT services). During 2015, more than 30 million orders were organized and executed using SUTI-compliant data communications. Notably, this transactional data specifi- cation was critical to the development of FlexDanmark, which is one of the largest—possibly the largest—public DRT systems in the world. It operates in six large service zones encompassing all of Denmark, averaging 16,000 rides daily with up to 24,000 rides per day. SUTI was formalized in 2002, and the role of the Swedish government in this process was crucial. Because the Swedish government is the primary funder of social services that involve transportation service for citizens, the Ministry of Transport was instrumental in the develop- ment and nationwide adoption of SUTI. Prior to the formal adoption of SUTI in 2002, there were strong pressures exerted on technology vendors by local governments and the national government to ensure interoperable end-to-end functionality of the key components of DRT technology: reservations systems; vehicle scheduling systems; taxi dispatch systems (almost all DRT in Sweden was delivered by the taxi industry prior to 2000); in-vehicle technologies (driver display units, card-based payment terminals, and vehicle location units); and payment systems. National-level adoption of SUTI was the culmination and formalization of develop- ments in this DRT ecosystem that stretched back more than a decade. The SUTI standard is utilized extensively in Denmark by FlexDanmark, a government- chartered service manager that aggregates demand for point-to-point trips from many sources, including municipal transportation services, school trips for students with special needs, hospital and other healthcare–related trips, and human service agency trips. FlexDanmark started in one region in Denmark using the technology solutions previously developed in Sweden. Through a strategy of expanding one geographic area at a time, the FlexDanmark system gradually took over operations of DRT in Denmark, with limited resistance to the use of SUTI. Major stake- holders such as Trapeze and Halda agreed that this was the way forward. The main reason for this was that SUTI rapidly became a Nordic standard covering Sweden, Norway, Finland, and Denmark, so these technology companies could save time and money on system-by-system implementation. The SUTI standard is a set of documents that are mostly open access; however, some docu- ments about use cases and SUTI attributes are exclusive to SUTI members. The development and maintenance of the standard is driven by member demands. A technical committee receives cases from its members—simple attribute cases or bigger projects. To work on bigger projects, the technical committee needs approval from the board. New versions of SUTI are released on a yearly basis. The SUTI standard has evolved and expanded significantly. The scope of the standard initially focused on the simple task of ordering a taxi for demand-responsive transportation from point A to point B. Over time, it has expanded to include the entire route of vehicle trips with multiple pickups and drop offs, as well as financial transactions and real-time status messages, such as arrivals or no-shows. In the SUTI standard, trips are described for the service provider (i.e., contracted vehicle operator) using the concept of telegrams. Telegrams consist of a specific message that includes certain standard mandatory and optional data elements. A new trip message, for example, includes specific types of information about the passenger’s origin and destination, pickup time, use of mobility aids, and other relevant data about the passenger trip. This message is sent electronically in a specific format defined by SUTI to a specific service provider’s dispatching (or scheduling) system, which contains software that examines the message, determines the message type, extracts the data elements it needs, and forwards the message to a SUTI-compliant

40 Development of Transactional Data Specifications for Demand-Responsive Transportation device in the vehicle to which the trip has been assigned. The software running on the device can then display the trip information to the driver at the appropriate time. The SUTI standard has developed a set of XML messages that can be exchanged between a client and a provider. XML, the eXtensible Markup Language, is a textual data format, readable by both machines and humans, that defines a set of rules for documents. It is commonly used for exchanging data between applications. In this case, the “client” has the travel demand infor- mation, which includes trip requests from customers wanting to use the demand-responsive transportation system. To fulfill these demands, the client can use one or several DRT service providers to fulfill the trips; it sends messages to request service. The current SUTI standard includes many different fields in a clear XML structure. Three main conclusions can be drawn from this example. First, the role of the Swedish government as a champion for the development of SUTI standards has been critical. The government was in a unique position to enforce data standards and stood to benefit from lower barriers to entry to the DRT market. Second, there are clear and measurable benefits from the widespread adoption of a transactional data specification. The SUTI specifications helped standardize trip request data across multiple platforms and service providers, which in turn helped lower costs of entry into the market and lower costs of DRT services overall. Last, this case study shows that the development of a transactional data specification is feasible, as the SUTI standard has been the foundation for all system interoperability in the Nordic countries. The example of the SUTI standard is summarized in Figure 3-9. 3.6 Comparison and Conclusions This chapter presented five examples of common data specifications or standards in the transportation industry. Some common themes and conclusions can be identified. Recognition of Benefits One common theme from the five examples is that interested parties will pursue data stan- dardization if they readily perceive how it benefits their organization, particularly financially. CASE STUDY SUTI in Scandinavia Who? Swedish Ministry of Transport and FlexDanmark, which is one of the largest public DRT systems in the world What? Transactional data standards for demand-responsive transportation in Scandinavia Why? To achieve financial benefits for local governments in Sweden and indirect benefits for technology providers How? Implementation of the SUTI standard by Swedish government; subsequent adoption by other Scandinavian DRT providers, including FlexDanmark Lessons Learned Transactional data standards for demand-responsive transportation are feasible and can have beneficial impacts for all affected parties. Governance Structure Swedish Ministry of Transport–organized governance committee of agencies, service providers, and technology companies ultimately responsible to government agency. Figure 3-9. Summary of the SUTI standard example.

Examples of Transportation Industry Data Specifications 41 In every case in which the data standards or specifications advanced, organizations were involved that clearly saw the concrete benefits of such standards and had a financial incentive to support their implementation and further development. For example, the airline industry could not function without the ability of airlines to exchange data on customer itineraries that involve multiple airlines. The airline industry participants all recognize the importance of the data exchange and have worked to achieve collective benefits from the framework that has existed for over 50 years. Similarly, Google Transit—a widely used application that works in conjunction with Google Maps—served Google’s financial interests because the more interest attracted to these applications, the more advertising Google can sell. Only by developing a universal data specifica- tion for fixed-route public transit services could Google make it feasible for hundreds of transit agencies to feed their data to Google Transit so that its consumer benefits could become widely accessible. In Denver, government-funded entities providing transportation recognized that without a data specification, transactional collaboration is not feasible; this led to a willingness to push forward with a specification process to obtain the benefits afforded by transactional capabilities. While benefits of transactional specifications for DRT may be recognized by DRT providers, individually they do not have the resources to pursue development and implementation. The entities with the resources—the public agencies that fund public transit services and those human service and healthcare programs that may require substantial DRT services for their clients— may not yet have recognized the benefits of a transactional specification for DRT. Role of Government Another noteworthy lesson is the important role of government in the Scandinavian case. The Swedish national government had a strong financial incentive to make it possible for any local government responsible for transportation services for older adults—services largely funded by the national government—to use any software system that could connect to any transportation provider so that services could be provided in the most cost-effective manner and promote a competitive transportation marketplace that would constrain costs in the future. FlexDanmark simply adopted the SUTI standards as a way of doing business and made it clear to its operational partners that they had to use SUTI-compliant technology in their business. The huge FlexDanmark market for transportation services, involving more than 500 operators, is only feasible because there is a common mechanism for moving data through the system. Successful implementation of a transactional specification in the U.S. context is likely to require similar motivations among participants in the DRT sector. If government-led initiatives similar to SUTI are not undertaken in the United States, what would induce transportation organizations to advocate for common data standards? Perhaps the prospect of lost potential revenues due to nonadoption of a specification would incentivize some private organizations to join with others to develop and implement a common specification in their technologies. In contrast, the now 5-year process to achieve official GTFS status for the GTFS-flex extension largely reflects a lack of strong support by local public agencies, of which only VTrans and Denver’s regional transit agency have been active. There is no discernible opposition to this extension of the specification, but with limited resources and the implementation requirement of the GTFS process, it has proven difficult to surmount the relatively modest hurdles to adoption.

42 Development of Transactional Data Specifications for Demand-Responsive Transportation Time to Implementation and the Evolution of Specifications Another common theme is the time required for implementation: how long it may take to develop, adopt, and integrate specifications into day-to-day activities and the evolution of specifications (or standards) over time. Initial development, adoption, and widespread adoption can take a decade or more. The passenger name record (PNR) system in the airline industry, GTFS, and the SUTI standards each evolved significantly over time; this points to the importance of developing a flexible, adaptable specification. It also points to the importance of a governance process that approves changes while maintaining the integrity of the specification. Technical and market considerations must also be taken into account, as discussed in Chapter 2.