TIDES Architecture Description and Diagram

[john....@metrotransit.org]

The Transit ITS Data Exchange Specification (TIDES) is designed to allow transit agencies to more easily share processes for accessing and managing intelligent transportation systems (ITS) data and share to reports and tools that use ITS data.

ITS data in this case refers to the information generated by automatic vehicle location (AVL), automatic passenger counter (APC), automatic fare collection (AFC), and similar systems.   Basic data elements include vehicle location information and passenger boarding and alighting data.

The structure of TIDES consists of databases to contain data, APIs to store and access data in the databases, and processors which access data with APIs and manipulate the data in different ways.

The TIDES architecture is modular and can be implemented either in whole or in part depending on the needs and resources of the transit agency.

Implementation Options

There are at least three different ways to implement TIDES within an agency.

1.     The entire TIDES architecture can be implemented by the agency, with databases and processors running on the agency’s servers.

2.     The TIDES APIs can be connected to existing data sources, without the use of the TIDES databases or processors.  This allows data to be accessed in a common format, but does not implement any of the other TIDES elements.

3.     The TIDES elements can be delivered through a software as a service (SaaS) model. In this model, the raw ITS data is extracted from the source systems and sent to a third-party service.  All the remaining TIDES databases and processes are implemented on that remote service and the processed data is accessed from that service.

The architecture is flexible to allow a mix of these options for different aspect of the TIDES system.

The primary elements of the Transit ITS Data Exchange Specification are as follows:

1.     Base Data Systems

The Base Data Systems are the existing data sources of the transit agency for AVL, APC, AFC, scheduled service, operated service, service standards, and other data.  These data sources and their structures vary from agency to agency.  Sometimes they are vendor systems, other times they are database built by the agency.

2.     Base Data API

The Base Data API provides access to the various Base Data Systems.  Since each agency uses different Base Data Systems, the back end of the Base Data API, that connects to the Base Data, will be different for each agency.  The front end of the Base Data API will provide a common data access format across all agencies that implement TIDES.

The Base Data API is a one-way interface.  It can only pull data from the source systems.  It does not have the functions to push data back into the source systems.

3.     Integrated Database

The Integrated Database initially stores a copy of each element from the Base Data.  This include each AVL, APC, and AFC record, along with the scheduled and operated service information.   The Integrated Database then has structures to connect these data elements together, for example linking a vehicle location record with a scheduled trip.  Finally, the integrated database includes a range of calculated fields, such as headway between trips or load on the vehicle, that are derived from the raw data sources.

4.     Integrated Data API

The Integrated Data API stores records into and retrieves records from the Integrated Database.   It is used by several TIDES processes and can also be used directly to access the integrated data.

5.      Data Integration Processor

The Data Integration Processor extracts data from the Base Data Systems using the Base Data API and stores it into the Integrated Database using the Integrated Data API.  The Data Integration Processor contains the logic necessary to link ITS events (AVL, APC, AFC records) with the scheduled trip information.  It also calculates certain fields such as vehicle loads and headways.   It is possible to have several different Data Integration Processors in operation that accomplish different tasks.  

6.      Data Quality Processor

The Data Quality Processor is really just an example of a Data Integration Processor. It is specifically designed to identify, flag and correct data quality problems in the data in the Integrated Database.   The specific needs and function of a Data Quality Processor will depend on the specific needs of a transit agency.  The types of errors that occur at one agency may not be a problem at another one.

7.      Aggregated Database

The Aggregated Database stores data that has been aggregated up from the individual data element of the Integrated Database.  An example might be daily ridership or on-time performance for a route. To speed access to this data, the agency may choose to calculate the value ahead of time and store it in the Aggregated Database. The specific needs of each agency will differ, so the design of the Aggregated Database will have to allow for generalized aggregated across different temporal, spatial, and organization scales.

8.     Aggregated Data API

The Aggregated Data API stores records into and retrieves records from the Aggregated Database.   It is used by the Data Aggregated Processor and can also be used directly to access the aggregated data.

9.     Data Aggregation Processor

The Data Aggregation Processor extracts data from the Integrated Database using the Integrated Data API and stores it into the Aggregated Database using the Aggregated Data API.  The Data Aggregation Processor is designed to handle the different types of aggregation that are possible.

10.  Data Summarization Processor

A Data Summarization Processor is similar to the Data Aggregation Processor, except it runs in real-time and is designed to quickly access and summarize the data. Depending on the specific needs, the Data Summarization Processor may pull data directly from the Integrated Database or Aggregated Database without using the APIs.  This will allow for delegated database tasks.

11.  Web Data API

The Web Data API provides data in JSON or XML format for use by web applications and other tools.  It can access data from several different sources including the Base Data API, Integrated Data API, Aggregated Data API and the Data Summarization Processor.

12.  General Notes

Because every transit agency will have its own nuances to the transit data and operations, the TIDES data structures and processes will need to be configurable.

Each provider of TIDES data will need to define which elements of the standard specification it supports, and each consumer of TIDES data will need to define which elements of the standard specification it requires.  This will allow system integrators to determine how to connect the two.­­­­­­­­­­­­­