Interface Design

The public portion of the interface design is broken up into two parts:

1. Inbound interfaces
2. Outbound interfaces

The Inbound interfaces refer to inputs into the system. These include:

1. Schedule Data; General Transit Feed Specification (GTFS) is used to specify static schedule data in a consistent manner. GTFS was created by google and is available here
2. Run, Trip, and DSC information; Should the GTFS not contain the complete schedule data, other input sources can be merged into the GTFS
3. Crew Assignment Data
4. Depot Data
5. Operator Data
6. Destination Sign Code Data
7. Pullouts Data
8. Agency Mapping Data ...
9. Service Alert Data; Service Interface for Real-time Data (SIRI) is currently used to describe service alerts (interruptions to service both scheduled and instantaneous). SIRI is a large and complex standard described here
10. Real-time Bus Data; Transit Communication Interface Profiles (TCIP), like SIRI is a large and complex standard attempting to standardize data exchange across transit agencies. Bus CIS Server uses TCIP to describe the real-time bus messages input into the system. TCIP is described here
11. Transit Data Service Input; JavaScript Object Notation (JSON); where there was no existing standard available, or adopting a standard proved too burdensome, interfaces standardize on simple JSON for data exchange. The messages input to the Transit Data Service from the inference engine queue are Plain Old Java Objects (POJOs) serialized to JSON. JSON is described here

The Output interfaces refer to RESTful-like services that allow data retrieval from the system, including both real-time and historical perspectives:

1. Operational API (RESTful service returns JSON) /todo move this content/
2. Historical API (RESTful service returns JSON) /todo move this content/
3. App Services
   1. SIRI SM (RESTful service returns JSON or XML)
   2. SIRI VM (RESTful service returns JSON or XML)
   3. SMS Interface (HTTP backing SMS messages returned directly to users)
4. TDM services: [TDM]
   1. Crew Assignment API (RESTful service returns JSON)
   2. DSC API (RESTful service returns JSON)
   3. Depot API (RESTful service returns JSON)
   4. Pullouts API (RESTful service returns JSON)
   5. QR coding API (RESTful service returns image/zipped folder of images)
   6. Configuration API (RESTful service returns JSON)
   7. Logging API (RESTful service returns JSON)
   8. API Key API (RESTful service returns JSON)
   9. Bundle API (RESTful service returns JSON)

Inference Engine Debugging Services

These are less a formal API and more UI pages that facilitate status and debugging informai

1. 1. Vehicle Tracking Webapp portal (HTML page which offers additional services)
      1. Current Vehicle Particles/Status (HTML page showing the most likely particle for each bus.  Can additionally access all particles for a vehicle from this page)
      2. Bundle Status (HTML page showing the currently deployed bundle on the IE.  Can additionally change to any IE stored on the TDM)
      3. Vehicle Simulator/Logged Data Playback (HTML page which allows replay of saved bus records (in csv or tab-delimited format)
      4. Data Debug/Sanity Check