University of California, Santa Barbara 


ITS and the Interoperability Problem

What is ITS? Scenario 1:  It's a foggy Friday night. John and Jane Doe are driving down a remote mountain track.  An errant deer (no relation to the Does) steps out of the bush.  The driver loses control, and the vehicle rolls down the cliff.  It could be a long time before the Does get help.  

Fortunately the Does have an intelligent vehicle.  An array of sensors note that the air bags have deployed, that there have been sudden changes in velocity and orientation.  The vehicle emits a digital mayday to the nearest 911 center, with details on the situation and a precise location reading.  

Scenario 2: You're on your way to an important meeting.  Traffic is backing up on the Interstate.  There's an alternate local route, but is it likely to be any better?  You consult the dashboard computer.  Using a Global Positioning System (GPS), it updates your location on a map every couple of seconds.  It is in touch with the Traffic Management Center (TMC) that monitors highway speeds.  It works out likely arrival times based on the latest observations: 11.24 a.m. using the local route, 11.47 a.m. along the Interstate.  

This is the arena of Intelligent Transportation Systems (ITS).  ITS can be applied to a variety of problems such as toll collection, fleet management, collision avoidance and autonomous control, tracking of weapons and hazchems in transit, coordination of transit schedules, and traveler information (e.g. where's the nearest motel with an available room).  

The ITS infrastructure — a high-tech dream that is gradually becoming reality — consists of a network of information exchange points including the “intelligent vehicle,” Emergency Management Services (EMS), TMCs and other Information Service Providers (ISPs), Electronic Toll and Traffic Management (ETTM) systems, roadside beacons and communications systems.

What is ITS?
The Problem
The Solutions
VITAL's Role
ITS Glossary/Links


The scenarios presented above are being tested by government and industry players in North America, Europe, Japan and Australia. Before they become part of our everyday life, some standards issues need to be resolved.  

A TMC broadcasts information on congestion, i.e. at such-and-such place the average velocity is so-and-so.  Velocity is straightforward, but how does it describe the location of this observation?  There are two aspects of interoperability:  

First, no two vendors' digital maps of the same area are identical in all respects.  Positional disagreement ranges from 0 to 150 metres.  Hence a location could be specified very precisely with respect to one map base, but when transferred to another vendor's map it could be off by a block.  

Second, there are several ways of describing a location, for example:  

  • Coordinates (e.g. latitude, longitude)
  • Route and distance (e.g. Interstate 95, mile 253)
  • Intersections (State Street and Eglinton Av)
  • Landmarks (Mission Hospital)
  • Map grid references (page 35, E-6)
Interoperability requires ready translation between these forms of messages.  Some data needs are more stringent than others.  For some purposes, measurement at the metre level is required; for other purposes 100 metres is sufficient.  But 100-metre data should not be used in 1-metre applications.  Data that are modified or coarsened by translation (e.g. a coordinates turned into grid references, and subsequently translated back into slightly different coordinates) must carry metadata tags reflecting their lineage. 

Here's one problem scenario: 

Three vendors, A, B, and C, offer databases for Santa Barbara county. The TMC adopts Vendor A, and broadcasts congestion data based on it. The Motor Club is based on Vendor B's map. A poor traveler has Vendor C's database on CD-ROM in his dashboard computer. He requests motel information from the Motor Club. When the data comes in and gets mapped on his system, his motel appears to be in the middle of a lake.  He asks for congestion data from the TMC.  It gets attached to the wrong network link because of coordinate misregistration.  The navigation system recommends a bizarre route to a lakefront. This is perhaps forgivable for someone looking for a motel, but not for an ambulance on an emergency call. 

Solutions? Initiatives at the international level (International Organization of Standards, ISO, TC204) and the national level in the U.S. (Society of Automobile Engineers, SAE, Recommended Practice J2256) and Japan (Vehicle Information and Communication System, VICS; Universal Traffic Management System, UTMS) have addressed the issue of messaging protocols.  They describe the makeup of various messages and the information fields that should be associated with each.  For example, a "Position Report from Road Side Beacon" is composed as follows (ISO Draft Recommended Practice, Version 1.3):  
  • Message code (16 bits)
  • Beacon ID (14 bits)
  • Beacon Location:
    • Standard location reference (64 bits)
    • Offset from reference point (16 bits for 1 metre resolution)
Two standards have been proposed by Oak Ridge National Laboratories (ORNL), Tennessee:  
  • The Location Reference Messaging Specification (LRMS) specifies messaging formats using a variety of referencing “profiles” such as coordinates and street names.
  • The ITS Datum (ITSD) is a proposed network of monuments (i.e. points with precisely measured locations, typically along major routes or in areas of high network density) that would permit registration of any data base to a common reference coordinate framework.  Linkage and attribute data may be included.
In theory these would address the above problems and be the basis of a location referencing standard, at least for ITS applications currently envisaged.  Are these the solution?  Will they solve the interoperability problem?  We need to find out.
VITAL's Role VITAL has vehicles in two-way communications with ground-based data servers in Santa Barbara.  The vehicles carry position sensors and precise odometers.  A selection of popular commercial data bases are installed in the servers and mobile units, and messages are exchanged between servers and vehicles.  Errors are systematically studied, and remedial measures evaluated.  

We address issues of interest to industry and academia, for example:  

  • How are nonconformity errors between two data bases spatially distributed?  What is the appropriate ITS Datum design to suit these error characteristics?
  • How effective is the LRMS at resolving referencing and messaging problems?  What errors are encountered, because of municipal street layout practices, database errors or shortcomings in the messaging protocol?
  • What additional problems are introduced by wireless communications technologies?  How do data losses impact the utility of driver information?  What sorts of data volumes can reasonably be transmitted using different technologies?  What ITS scenarios are practical within a given time frame?
  • How do drivers respond to highway information?  How does this affect utilization of the highway system?  How do user interface designs impact drivers?  Are there safety concerns?
  • What are the capital and recurring costs of implementing the technology on a large scale?  What are the benefits?
Special-interest organizations such as Emergency Management Systems (EMS) groups and fleet managers may have specific research problems in ITS; and research groups will inevitably propose solutions on data models, protocols and communications technologies. VITAL is a functioning test site — associated with a highly reputable GIS research institution — with the ability to test proposals and to offer innovative solutions.  

These efforts will help future ITS planning, shorten travel times, improve highway utilization, and perhaps save the Does and their deer friends.  

Technical details on our work



ITS User Services as defined in National ITS Architecture 
ITS Glossary (with links to some ITS organizations)