Our previous World Congress and Intelligent Transportation Society of America

Paper presented at the Second World Congress on Intelligent Transport Systems, November 9-11, 1995, Yokohama, Japan

SWIFT: Technical and Institutional Issues of an Operational Test from a Public Sector Perspective
Daniel J. Dailey Dept. of Electrical Engineering College of Engineering University of Washington Seattle, Washington 98195 Mark P. Haselkorn Dept. of Technical Communication College of Engineering University of Washington Seattle, Washington 98195

ABSTRACT This paper provides an overview of the Seattle Wide-area Information for Travelers (SWIFT) project. The SWIFT project delivers traffic and traveler information via FM subcarrier to hand-held wireless devices as well as in-vehicle devices. SWIFT is an unusual public/private partnership in which the public sector takes the responsibility for obtaining and formatting data for use by the private sector. In this paper we discuss the technical design of the SWIFT project, and we also examine the institutional issues inherent in implementing both the technical design and the public/private sector collaboration. 1. INTRODUCTION Our previous World Congress and Intelligent Transportation Society of America (ITS America) presentations have described the ITS architecture developed in the Puget Sound region [1] as well as ITS/ATT applications that take advantage of this regional architecture [2]. In this paper we describe a major operational test known as SWIFT for Seattle Wide-area Information for Travelers. SWIFT relies on the Puget Sound regional architecture as its backbone communication infrastructure. This Operational Test involves the collaboration of public-sector agencies and privatesector companies to test the viability of delivering traveler and traffic information over a wide area using wireless technology. 2. GOALS, OBJECTIVES, AND COMMUNICATION Public/private partnerships are a delicate balancing act because these partners often have very different goals and motivations. SWIFT has a broad range of goals and objectives (see Figure 1 for the table of goals and objectives as listed in the original proposal), and different goals tend to be emphasized by different groups. For example, the private sector is likely to focus on objectives under Goal V related to the development of a viable product, while the public sector is


Table of Goals and Objectives GOAL I. Evaluation of institutional issues Objectives: 1. Maintain library of all contracts and agreements. 2. Document methods used to promote institutional cooperation and identify effectiveness. 3. Maintain records of meeting minutes, briefings, and/or handouts. 4. Assess partners’ attitudes (before, during, and after participating in the operational test) toward applications of IVHS technologies in a public/private partnership environment. 5. Identify future applications and improvements of the HSDS technology and test devices. 6. Document policy and jurisdiction issues. GOAL II. Evaluation of the efficacy of the HSDs transmission network Objectives: 1. Assess performance of communication system. MOEs include message error rate (MER) and signal in noise and distortion (SINAD). 2. Assess different station operating characteristics, including the impact of antenna height, processing, presence of other subcarriers, etc. on MER. (The operational test will uses STS’ existing radio network which includes a variety of stations with different operating characteristics.) 3. Assess ability of HSDS communications channel to serve rural and urban ITS communication needs. GOAL III. Evaluation of cost and technical interface factors Objectives: 1. Assess performance impact of use of fewer FM radio stations. 2. Assess performance impact of reducing message retransmission. 3. Assess user interface, including ability of test devices to convey information to users. MOE is user testimony. 4. Document costs of operational test. MOE is actual costs. 5. Estimate costs of deployment. MOE is estimated costs.


GOAL IV. Objectives:

Evaluation of operating parameters, and network and system architecture requirements 1. Determine optimum packet length. Measure MER vs. SNR for different packet sizes. 2. Determine impact of error correction coding; determine optimum code. 3. Assess impact of space and frequency diversity.

GOAL V. Evaluation of consumer acceptance of test devices Objectives: 1. Assess willingness to pay for different devices and services. MOE is amount of money consumer is willing to pay. 2. Assess user’s perception of system usefulness. MOE is user testimony. 3. Assess utility of watch as a low-end device in providing TIS to users. MOE is user testimony. 4. Identify minimum set of user services required to provide viable products/services. GOAL VI. Evaluation of potential impact on transportation performance Objectives: 1. Assess changes in travel time (MOE is travel time), congestion level (MOE is delay), travel distance (MOE is vehicle travel miles/day/week/month), and travel patterns (MOE is time of departure, route selection, mode choice). 2. Assess reliability and availability of the test device. MOE is probability that test device will perform its design function for a given period of time. 3. Assess the environmental impact through modeling studies. MOE is pollutant reduction. 4. Assess safety impacts. MOE is accident reduction. 5. Assess impact on mode selection. MOE is change in mode selection. 6. Assess the accuracy of trip travel times. MOE is predicted versus actual travel times.

Figure 1 Evaluation goals, objectives and measures of effectiveness (MOE) taken directly from the SWIFT proposal.


likely to focus on impacts on transportation performance such as reduced congestion and increased safety (Goal VI). Given these perspectives, the relationship between the public and private sectors is often one of the public sector purchasing services from the private sector. While it is not unusual for the private sector to take public data and add value to it to create a product, it is unusual for the public sector to actively modify and repackage its data to facilitate private sector development. This is precisely the case in SWIFT. The project is a partnership of three public-sector entities--the Washington State Department of Transportation (WSDOT), King County Department of Metropolitan Services (METRO), and the University of Washington (UW) and five private partners--Seiko Telecommunication Systems, IBM, Delco Electronics, Etak, and Metro Traffic Control. Much of the SWIFT data is obtained and formatted by the public-sector partners and handed off to the private-sector partners to create value-added services. This hand off is accomplished through the collaborative definition of three key communication components: (1) the content of the messages, (2) the structure of the messages, and (3) the interfaces between the public and private-sector partners. These three key definitions are at the heart of the ability of the public and private sectors to partner despite their differing goals and motivations. We therefore examine each of these communication tasks in more detail. 2.1. Content of Messages The first communication task is the definition of message content. Traveler and traffic information can be delivered using a wide variety of media and with varying levels of fidelity. The level of fidelity is often determined by balancing costs and benefits. The benefit to the user is typically proportional to the amount of information that can be conveyed to the traveler (up to the point of information overload), however, the costs of the infrastructure rise as the information content becomes more complex. The trade off between cost and benefit is a market analysis based on the perceived added value. For the SWIFT project four issues arise in determining what the content of the data flow will be: (1) available technology, (2) legal and copyright issues, (3) perceived value of the data, and (4) financing. The first step in determining message content is to identify what is possible within the technology available to the public sector data providers in the time frame of the operational test. For example, it is envisioned that there will be large numbers of probe vehicles in the Puget Sound region in the next ten year. In the SWIFT time frame, however, only the dead-reckoning based automatic vehicle location system (AVL) operated by METRO Transit will be available to make travel-time estimates based on probe vehicles. A second example is that of WSDOT who is installing additional traffic sensors, including speed and classification loops as well as additional CCTV cameras, however a large portion of the deployed equipment consists of single inductance loops that measure 20 second averaged volumes (number of cars) and occupancies (the fraction of the time the loop is occupied). The

implication of the WSDOT infrastructure is that while the private-sector partners may desire speed on each segment of highway as a data item, the data-fusion partner (UW) is actually building estimates of speed rather than having access to measured values. The second issue in determining the content of the data flowing from the public sector to the private sector, involves both legal and copyright issues. The public sector has purchased equipment and software from various vendors to implement the surveillance and control systems that the private-sector entities rely upon for data. In some cases copyright and other legal restrictions, such as nondisclosure statements, prevent public-sector entities from disclosing sufficient information to allow the private sector to have full access to the information available to the public-sector agency. The third issue in data content is the perceived value of the data items to the private sector. The public-sector agencies, in many cases, collect much more data at a finer time granularity than the private sector perceive as useful as a base for value-added products. This comes about as a result of the public sector’s mission to provide surveillance and control while the private sector’s goal of value-added information has inherently less stringent data acquisition needs. The fourth and final issue driving the content of the data being shared is the financing of the project. Each partner has a contract to accomplish a fixed set of tasks for a fixed amount of money. So although there may be additional sources of data available, it may be prohibitively expensive to include this data in the SWIFT project. Two examples of this are the doppler radar information used to identify precipitation and the CCTV camera pictures. Both of these could be included with significant additional resources, and these types of data might be of great value but are outside the scope of the SWIFT project. The definition of the content of the information delivered in the SWIFT project is driven by technology, legal issues, perceived value, and financial constraints. The result is that the selected data components are: (1) best-estimate link speeds produced by the UW from a combination of WSDOT’s single loops and speed traps as well as METRO transit vehicles tracked in real time so as to become probe vehicles, (2) real-time transit vehicle locations in latitude and longitude, produced by the UW from a set of routes and real time odometry information from the transit vehicles, (3) ridesharing information from the UW in the form of paging messages, (4) downloads of databases of information, such as bus and ferry schedules, (5) text messages, created by Metro Traffic, describing traffic incidents, (6) differential GPS range corrections from Seiko, (7) ReceptorTM Information Services, such as weather, stock market reports, and sports scores, and (8) Personal Pager Messages. These basic pieces of information are used by the private sector to produce the traveler information products deployed on pen computers, watches, and car radios.


2.2. Definition of Structure The second communication task that enables the hand-off of data from the public to the private sector is defining the structure of the communication between the information sources and the deployed devices. The SWIFT project uses a variety of information sources and delivers the information on several platforms. The fidelity of the information that can be delivered is limited by either the capabilities of the end-user device, as in the cases of the watch and the radio, or the bandwidth of the wireless communication media, as in the case of the hand-held computer. In either case the information must be sent through Seiko’s wireless High Speed Data System (HSDS) in such a way that the receiving end can interpret the information and convey it to the end user with the highest fidelity possible for that specific end user device. The Electronic Digital Interchange for Advanced Communications Transport (EDIFACT) standard was chosen to transfer traffic/traveler information in the SWIFT project. The EDIFACT standard provides an efficient means of guaranteeing accurate communication over the HSDS. It provides: (1) a database of messages that is shared by both ends of the communication, and (2) a common messaging format to encapsulate messages from the shared database for transmission over HSDS. To transfer information in an EDIFACT style the information source first consults the dictionary of possible messages and selects the most appropriate for the situation. This message is represented by a relatively short code, and this code representing the extended message is the only thing transmitted across the communication media. The user device receives the code and converts it back into the extended message by consulting the peer data base maintained on the user device. This method effectively compresses the information to be transferred by defining the information in terms of a shared database. The International Traveler Information Standard (ITIS) is a proposed standard for EDIFACT messaging in the traveler/traffic information arena. For the SWIFT project the HSDS Bearer Application Protocol specifies a means of applying the proposed ITIS standard to Seiko’s wireless technology. The partners, lead by Seiko, have developed an open non-proprietary HSDS-BAP [3] that specifies the list of messages and the message format for use in traffic/traveler information applications over an HSDS. This definition for the structure of the information allows the information providers to encode the information efficiently while the message definitions allow the messages to be device specific. This style of messaging allows for efficient use of Seiko’s HSDS and provides a defined structure for the information providers to build packets of data of appropriate size and format to interface with the HSDS. 2.3. Definition of Interfaces The third communication task to enable transfer of information from the data sources to the deployed devices is the definition of the interface between the partners. The Puget Sound Regional ITS backbone is a set of protocols and paradigms that allows sharing of data between multiple autonomous agencies [1]. The Puget Sound Regional ITS backbone is built upon the Internet protocol suit, and

the applications to date have been written to operate on a “sockets” programming interface. The SWIFT project also uses the internet protocol suit for network data transport. This allows the partners to be located anywhere on the internet or to select private data lines for interconnection. The data transfer between the data sources and the HSDS is done in an atomic manner using a specified HSDS-BAP packet for each type of message and encapsulating it in the Transport Control Protocol (TCP) from the Internet suite. The UW has constructed interfaces to WSDOT’s Traffic Management System (TMS) and to METRO’s Automatic Vehicle Location System that allow the raw data from each of these sources to be available on the ITS Backbone. This data is combined to provide optimal estimates of link speed and transit vehicle location for transmission to the information delivery platforms. 3. TECHNICAL DESIGN The technical design of the data source systems of the SWIFT project is driven by the factors outlined in the previous section. The three basic functions that are performed by the data providers are: (1) data collection, (2) data fusion, and (3) data encapsulation. Each of these functions has a public sector and private sector component. We examine each of these functions as performed by both the public and private-sector entities. An overview of the data flow is shown in Figure 2. The three groupings in the diagram are indicative of the location and implementor of the functions shown in the boxes. The left most grouping of functions takes place at the UW, the top right grouping takes place at Seiko’s facility and the bottom right grouping takes place at METRO Traffic Control. The ITS backbone paradigm facilitates making these functions independent of geographical location so that while the public-sector data comes from both WSDOT’s Northwest Region headquarters in north Seattle and METRO Transit’s AVL operations center in downtown Seattle, Seiko can interleave the information into their FM subcarrier data stream at a location yet to be chosen, possibly as far away as Portland, Oregon. SWIFT data collection begins at four sources. Three are public-sector sources, and one is from the private sector. The public-sector data sources are: (1) loop data from WSDOT indicated by Vol (volume: count of vehicles per unit time from a single inductance loop), Occ (occupancy: the fraction of the timer that a single inductance loop is occupied by a vehicle), and Speed (average speed from two loop speed traps); (2) AVL data from METRO Transit indicated as Routes (a series of geographical locations placed sequentially in a file), Distances Along Routes (distance from the first geographical location on a route to the current location of the vehicle), and Status (a code indicating such parameters as type of route, type of vehicle, schedule adherence, etc.); and (3) rideshare data from UW about potential participants in dynamic carpools. The fourth data source is from the private sector: traffic reports gathered by Metro Traffic Control from aircraft, cellular callers, spotters on buildings, and police reports.

Vol Occ Speed Probe Vehicle Travel Time Routes Distance Along Route Status Data Fusion Transit Vehicle Position ITIS Encapsulation Ride Share DB ITIS Encapsulation Data Fusion Link Speed ITIS Encapsulation

Differential GPS Paging Informational Messages


Seiko HSDS

ITIS Encapsulation



Cellular Spotters Police

Metro Traffic Workstation

Metro Traffic

Figure 2 Overview of data flow for the data providers. These four data sources are used to generate four types of data streams for eventual transmission via the HSDS. After data fusion, these four data streams contain (1) maximum likelihood estimates of travel speeds on regional freeways, (2) estimated current locations of Metro buses, (3) selected elements from a database of information on potential rideshare participants, and (4) reports on traffic related incidents at various locations. The link speeds are estimated using a Kalman filter which is a maximum likelihood technique to combine the single loop estimates of volume and occupancy (available on all links) with speed trap data (available on some subset of the links) and probe vehicle travel times (created by recording the transit vehicles location as a function of time as they travel down the highway). The transit vehicle locations are estimated by combining apriori knowledge of the routes with real time odometry information indicative of the distance each vehicle has traveled along its assigned route. This provides a “linear reference model” location (the location on a predefined line). A nonlinear coordinate transformation (using a Newton’s method) is then applied to the “linear reference model” location to convert the location representation into the cartographic system used by the mapping partner Etak (latitude and longitude). This latitude and longitude location

of individual transit vehicles is the content of the transit vehicle position data stream. Rideshare information includes a participant’s location, destination, willingness to drive or ride, and desired time of departure. This information resides in an SQL database and is processed to generate paging messages that are encapsulated prior to HSDS transmission. Traffic reports are entered into a traffic workstation using a graphical interface. This interface allows operators who are in touch with the various data sources to quickly locate textual messages at geographical locations. All of the data types are encapsulated in a standard way before transmission to Seiko’s HSDS. SWIFT data encapsulation uses the ITIS standard to define the structure of communication between data providers and data consumers as discussed earlier. Each of the data streams is formatted and encapsulated into one of the specific EDIFACT types that are defined by Seiko in the HSDS-BAP [3]. The hand off from the public-sector data sources to the private-sector wireless provider takes place at the communication interface where the traffic and traveler information, encoded in a standard format, is passed to Seiko’s HSDS for transmission. The private sector can then obtain this information from the Seiko data stream, add value to it, and present it to the user in a way best suited to their product (an example may be found in [4]). 4. CONCLUSION The SWIFT project is a unique public and private sector partnership in which data obtained by several public- sector entities for surveillance and control tasks are combined to provide an information stream to which the private sector can add value. The differing goals and objectives of the public and private sectors are met by defining the content and structure of messages to be passed between the participants and defining the interfaces through which the messages are passed. The success of projects like SWIFT requires the development of methodologies like those presented here to facilitate public and private sector partnerships. 5. REFERENCES [1] Dailey, D.J. and M.P. Haselkorn, “A Conceptual Framework for IVHS System Development,” Proceedings of the 1993 Annual Meeting of IVHS America, Washington, D.C., April 14-17, 1993, pp. 1-7. [2] Dailey, D.J. and M. P. Haselkorn, “Demonstration of an Advanced Public Transportation System in the Context of an IVHS Regional Architecture,” Proceedings of the First World Congress on Applications of Transport

Telematics and Intelligent Vehicle-Highway System, Palais de Congres de Paris, France, Nov. 30 - Dec., 3 1994, pp. 3024-3031. [3] Gaskill, G. and J. Sullivan, “High Speed Radio Data System Bearer Application Protocol (HSDS-BAP,” Seiko Communication Company Document No. 1009SPC-0004-00, 1995. [4] Doganata, Y., D .Gazis, and A. Tantawi, “SWIFT Personal Digital Assistant (PDA) Functional Specifications,” IBM Research Division, Research Report, May 1995.



Intelligent Transport Systems (ITS)

Furthermore, through Global Positioning System (GPS...However, technology in the past does not able ...“Intelligent Transportation Systems – Where do we...