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.
36 Figure 3-1: Standard versus Specification : Examples of Transportation Industry Data Specifications Companies and organizations in many industry sectors 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 example 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, APIâis noted for each situation. These examples are explained in a non-technical manner so that they are accessible to those without significant information technology experience. It is important to note the key difference in terminology between specification and standard, as initially described in Chapter 2 (see Figure 3-1). Some of these examples, e.g., 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 General Transit Feed Specification does not. 3.1 Example 1: Airline Reservations 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 have 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 system to share information about airline 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 the itinerary was booked on. There was a need to transmit the data for the flights on the other airline(s) Standard: documented technical requirements that have been agreed upon by consensus or established by a neutral third party. Specification: documented technical requirements generally considered working or business documents.
37 to the computer reservation systems of those airlines, where a new record could be created in the other airlineâs system that included most or all of the 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 very detailed and comprehensive set of data message specifications focused on what is known as the Passenger Name Record (PNR) was developed. These message specifications are managed by the Air Transport Association, the trade association for the U.S. airline industry, and the International Air Transport Association, 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, which is typically referred to as a Computer Reservation System has its own proprietary standard for these messages. However, common industry needs, including the need to map PNR data easily to the messages, has resulted in many similarities in data content and format among all of the major airlines for the PNR. Key pieces of PNR data are summarized in Figure 3-2. Figure 3-2: Airline Passenger Name Record (PNR) Contents When a passenger books an itinerary, this action results in the creation of a PNR in the airlineâs own Computer Reservation System (CRS). The PNR is identified by a record locator, which is 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 other Computer Reservation Systems of the airlines that are 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, then this information will be pushed back from the PNR associated with that airline to the master PNR of the originating airline. Passenger Name Record (PNR) contents: â¢ Record locator (identifier): 6-character value â¢ Name of the passenger â¢ Contact details for the travel agent or airline office â¢ Ticketing details, either a ticket number or a ticketing time limit â¢ Itinerary of (at least) one segment, including origin and destination airports, airline, flight number â¢ Name of the person providing the information or making the booking
38 The PNR-focused system of data messages continues to exist today and has been extended to hotel and rental car reservations booked in conjunction with airline travel. Moreover, there is a substantial amount of âoptionalâ data items (i.e., not related to actual travel) that often need to be transmitted as part of the messages using the PNR framework. Consequently, the PNR system has to be adaptable and flexible to handle these situations. These âoptionalâ data items include information that is important for airlines and travel agents, such as the following: â¢ 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 â¢ Seat allocation More recently, governments began requiring airlines to provide further information to assist investigators tracing criminals or terrorists such as gender, passport information for international travelers, and redress number if applicable. Changes to the data specifications system used by the airlines are more complicated today due to the fact that 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 such as online travel agencies like 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 technology 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 contain the functionality to handle these newer forms of pricing tickets that separate prices for specific services rather than a single price for the ticket and seat. Other initiatives, now brought together and formalized under IATAâthe governance body for the PNR specificationâhave extended specifications to these areas. This demonstrates the importance of having a formal means to achieve consensus on key transactional data specifications over time as changes occur.
39 Figure 3-3: Summary of Airline Passenger Name Record Example 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 that enables transit organizations to publish the real-time location of their vehicles and their schedule adherence on the web. This current example is focused on the core GTFS system. This specification was initially established by Google in partnership with Portland, ORâ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 a trip planning feature known as Google Transit. This collaboration resulted in the Google Transit Feed Specification. In 2005, TriMet became the first transit agency to publish their data in GTFS format. Since then, hundreds of CASE STUDY: Airline Booking Data Standard Who? International Air Transport Association (IATA) and Air Transport Association of America, which are trade organizations for the airlines What? Data about individual passenger's iterinaries (e.g., flight number, origin airport, destination airport) Why? Passengerâs can travel on more than one airline in an iterinary, so this data needs to be shared between airlines How? Passenger Name Record (PNR) Lesson(s) 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 the global distribution systems, were the impetus behind the PNR system, not technology companies. Governance Stucture for Data Standards: IATA publishes and maintains PNR data specification document and coordinates additional data specification initiatives.
40 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-4. Subsequently, the Google Transit Feed Specification was renamed the General Transit Feed Specification, and now, it is maintained by a community of transit agencies, software developers, transit planners and other stakeholders. It is worth noting that 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. There are six mandatory tables and another seven optional files that each 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-5, which includes a brief description of each. Figure 3-4: Google Transit Interface, which relies on GTFS data
41 Figure 3-5: Mandatory GTFS Content Typically, each transit agency or operator creates their own GTFS feed, which is usually updated whenever the transit agency changes its schedule (generally three or four times per year). These static GTFS feeds are then provided directly to Google for use in Google Maps. Additionally, 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. One final distinction about GTFS is that this dataset can be used in applications (such as Google Transit) to convey different fixed route transit trip possibilities 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ââ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 (see Figure 3-6). These differences are discussed in more detail in the next case study on an extension of GTFS for flexible services, which include DRT. The current GTFS example is summarized in Figure 3-7. 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 Discovery Data: Describes transportation service characteristics, such as where services and facilities can be accessed and when, and is primarily used by passengers for trip planning purposes including Transactional Data: Includes all of the data necessary for a passenger to actually engage a transportation service provider to book, schedule, and complete a trip, including payment information. ZIP GTFS Figure 3-6: Discovery versus Transactional Data
42 Figure 3-7: Summary of GTFS Example 3.3 Example 3: General Transit Feed Specification for Flexible Transit (Publish and Subscribe) This example is closely linked to the previous one, and it concerns an in-progress proposed extension of GTFS known as the General Transit Feed Specification for Flexible Transit, or GTFS- flex, that can accommodate certain forms of demand responsive transportation services. This example shows that specifications are not static, but rather continue to evolve. Indeed, GTFS has several off-shoots, including GTFS-RealTime. Another way in which GTFS-flex is relevant is that it will transmit some information (e.g., eligibility requirements) that could interface with DRT transactional specifications in the future. Finally, it illustrates a manner in which a specification 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 precisely described 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 they are directed to), 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. The typical means by which GTFS-flex data would be used is that a prospective traveler enters his/her origin and destination, such as in a trip planning application, and the system informs them of any services that are 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, transit maps, and/or transit schedule information into software applications, such as Google Transit How? General Transit Feed Specification (originally known as the Google Transit Feed Specification) Lesson(s) 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
43 available and where and how they can be accessed. This would include providing the customer with operating hours of the service, where pickup points are located if only discrete locations are served, and a telephone number or web site 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 a trip when they want as it has no access to transactional data such as where vehicles are currently located or vehicle availability for a specific time of day or trip from a specific origin to a specific destination. GTFS-flex proposes a few noteworthy additions and changes to the original GTFS format to accommodate demand responsive and flexible transit services. First, GTFS-flex introduces a new file known as âarea.txt,â which accommodates the fact that many DRT services operate with a specific geographic area. Second, three of the mandatory files (stop_times, routes, and trips) from the original GTFS format are modified to accommodate various types of DRT services (shown in Figure 3-8). Figure 3-8: Examples of Changes to Mandatory GTFS Files in GTFS-flex 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 accommodated 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 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 are as follows. 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 underway to try to formalize GTFS-flex. GTFS-flex is still in a prototype phase, which includes a recent âAlphaâ launch on DRT services in the state of Vermont. This alpha stop_times.txt â¢Numerous modifications, including accomodating point and route deviations routes.txt â¢Additional field to accomodate elibility requirements of DRT riders trips.txt â¢Numerous added fields to define service parameters, such as maximum travel time
44 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. There is also an intent by the transit agency in Denver to incorporate GTFS-flex into its trip planning capabilities and the process necessary for this to eventually occur has been initiated. To help manage extensions or changes to GTFS, there is a process that can be 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, there has been one âprototypeâ release in Vermontâ albeit for actual services, another actual implementation orchestrated by a large consulting firm (Cambridge Systematics) that is committed to this new specification. Until GTFS-flex is âofficiallyâ implemented in Denver by the transit agency there, 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 step(s) of formally incorporating GTFS-flex into the GTFS specifications. This example demonstrates the challenges to both gaining transit agency support and actually achieving formal official status for new specifications merely for DRT discovery data; formal transactional data specification implementation would appear to be a larger challenge. The example of GTFS-flex is summarized in Figure 3-9. Figure 3-9: Summary of GTFS-flex Example CASE STUDY: General Transit Feed Specification for Flexible Transit (GTFS-flex) 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 Lesson(s) Learned: Creating specifications is easier than achieving their real world implementation; transit agencies are key to supporting implentation Governance Structure: Same as for GTFS, Google as curator plus advisory group
45 3.4 Example 4: DRT Transactional Data in the Denver Trip Exchange Project (RequestâResponse, Publish and Subscribe, Open APIâhybrid) The fourth example concerns the Trip Exchange, a web-based system developed as part of an FTA- funded Mobility Services for All Americans (MSAA) project. The origin of the Trip Exchange software (not the concept, which had been discussed in Denver since 2010) was an actual implementation 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 in particular is designed for more fully automated processes. 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 for the purpose of enabling transactions amongst them. There are four DRT providers involved in the project, which include the following: â¢ 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; â¢ City and County of Broomfield, which provides transportation to eligible community residents â¢ Two human services transportation providers, which are: ï Senior Resources Center, which is the largest senior citizens program in the Denver area; this organization 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 non-profit agencies; also a major contractor for the RTDâs general public DRT program (note that this is not Via the shared ride van TNC company that operates in several cities in the U.S.) Additionally, two technology companies are involved in the project: DemandTrans Solutions and Routematch Software. These organizations are summarized in Table 3-1.
46 Table 3-1: Parties Involved in the Trip Exchange Project 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 Develop Trip Exchange hub; interface its DRT technology platform (for RTD DRT services) to Trip Exchange hub RouteMatch Adapt RouteMatch software, which is used by all providers other than RTD, to interface with Trip Exchange hub The Trip Exchange works as follows: 1. The DRT providersâand soon other human service organizations that need transportation for their clientsâare able to 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. 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 web siteâ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.
47 7. In the case when the trip delivered, the Trip Exchange then 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 who have previously agreed to transport each otherâs clients on a routine basis without trip by trip approval. Each provider can program their 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 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. As inferred above, 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-10 on the next page 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 2019 (using funds from another federal transportation project obtained by the Denver region) to address billing and financial requirements and to provide more options for multi-lateral 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.
48 Figure 3-10: Denver Trip Exchange Hub Structure 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 where individual providers have their own methods of booking and scheduling trips. This means that the exchange allows human service transportation providers to âseeâ trip requests (visually or via automated mechanisms) and determine if they can add a trip to an existing vehicle run, which is important given limited vehicular and driver resources. This supports â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 platform to enable inter-operability among DRT systems. The data specification developed for the Trip Exchange is fundamental to its workings and represent the result of a collaborative process involving many months of work by both technology-focused participants and operations-focused participants. While that specification is different from the one developed in this study, it also explicitly supports the trip life cycle and transactional processes and shares some important commonalities about core messages and the data they need to contain. In addition, the Exchangeâs data communication paradigmâa hybrid of a published API to enable software systems to transmit data to and from the Exchange, a reply-response mechanism to advance transactions, and a publish and subscribe mechanism to notify participants when new trips of potential interest are posted to the
49 Exchangeâillustrates the importance of the 3 data communication models as organizing concepts for enabling transactional data flows. With the current data foundations of the Trip Exchange in place, the organizations who 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-11. Figure 3-11: Summary of the Denver DRT Trip Exchange Example 3.5 Example 5: DRT Transactional Data Standards in Scandinavia (Request- Response) The final example in this chapter is the Scandinavian standard for DRT transactional data, known as SUTI (Standardiserat Utbyte av Trafik Information). This is the only known widely used data specification for DRT, and therefore, it is particularly relevant to this project. SUTI today is the standard throughout Sweden, Norway, Finland, and Denmark for the exchange of DRT CASE STUDY: Denver MSAA Trip Exchange Project Who? Denver RTD, Via Mobility Services, Senior Resources Center, City of Broomfield, DemandTrans Solutions, RouteMatch What? Trip Exchange for transactional DRT trip coordination between organizations who need additional transportation services and those who 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 Lesson(s) 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
50 information between providers (i.e., contracted vehicle operators) and their clients (i.e., the organizations that are responsible for DRT services). During 2015, more than 30 million orders were organized and executed using SUTI-compliant data communications. Notably, this transactional data specification 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 development 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 developments in this DRT ecosystem that stretched back more than a decade. The SUTI standard is extensively utilized in Denmark by FlexDanmark, which is 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 health-care 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 stakeholders 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 documents 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. The cases can be either simple attribute cases or bigger projects. In order to be able 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
51 specific types of information about the passengerâs origin and destination, pick-up 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 then forwards the message on to a SUTI-compliant 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 is an abbreviation for the Extensible Markup Language, and it is a textual data format that is commonly used for exchanging data between applications. In this case, the âclientâ has the travel demand information, 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. Figure 3-12 provides a definition of the SUTI message format. 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-13. . Figure 3-12: SUTI Message Format Telegram: a message that transmits data with a specific structure and wording (i.e., data elements) XML: a textual data format that defines a set of rules for documents that is both machine- and human-readable. It is one of two commonly used formats (along with JSON) for exchanging data between applications.
52 Figure 3-13: Summary of the SUTI Standard Example 3.6 Comparison and Conclusions This chapter presented five examples of common data specifications or standards in the transportation industry. Based on these examples, some common themes and conclusions can be identified, which are briefly discussed in the following paragraphs. Recognition of Benefits One common theme from the five examples is that interested parties will pursue data standardization if they are able to readily perceive how it benefits their organization, particularly financially. In every case where the data standards or specifications advanced, there were organizations involved in the process 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 eyeballs that are attracted to these applications, the more advertising it can sell. Only by developing a universal data specification for CASE STUDY: SUTI in Scandinavia Who? Sweden 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 govenment; subsequent adoption by other Scandinavian DRT providers, including FlexDanmark Lesson(s) 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 which is ultimately responsible to government agency.
53 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 in order 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 health care programs that may require a substantial amount of 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 the 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. Then, 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 over 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 U.S., what would be the inducement for organizations in this sector of transportation to advocate for common data standards? Perhaps the prospect of loss of potential revenues due to non-adoption 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 five-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 the regional transit agency in Denver have been active in this process. There is no discernable 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. Time to Implementation and the Evolution of Specifications Another common theme is the 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 had significant evolution over time. This points to the importance of developing a
54 specification that is flexible so it can be adapted. It also points to the importance of a governance process to approve changes while maintaining the integrity of the specification. In addition, technical and market considerations must also be taken into account, as discussed in Chapter 2.