ITS Transit Standards Professional Capacity Building Program
Module 3: Transit Communications Interface Profiles (TCIP), Part 1 of 2: Introduction to the Standard and Transit Architectures
HTML of the Student Supplement
(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
Module 3: Transit Communications Interface Profiles (TCIP), Part 1 of 2: Introduction to the Standard and Transit Architectures
Table of Contents
Introduction/Purpose - 2
Examples - 3
Case Study - 9
Glossary - 14
References - 16
Study Questions - 17
This course (TCIP 1) is the first of a two-module set on TCIP. This course will provide an introduction and overview of TCIP, concentrating on the contents of Volume 1 of the standard. The module describes the components of the standard, including the development of a transit agency architecture as a framework for procuring and implementing ITS systems, introduces the concepts of operations that illustrate how various business systems can be configured to exchange information, and describes the structural building blocks, data elements, data frames, messages and dialogs, that are used to standardize the exchange of information.
Transit Communications Interface Profiles (TCIP) was developed to be the ITS standard for transit management communications. This module is important because it introduces TCIP as a standard framework for exchanging data among various modules and systems used by transit agencies, which may be supplied by different vendors. TCIP capabilities include providing a library of data elements, data frames, messages, and dialogs that can be implemented using Extensible Markup Language (XML).
TCIP is published in four volumes. The standard is accessed by users through a suite of tools available as free downloads from the American Public Transportation Association (APTA). TCIP Volume I contains an introduction and overview of the standard. It includes concepts of operations for ten business process areas common to many transit agencies:
Volume I also provides guidance on conformance and procurement. Volume II contains four separate annexes containing: data element definitions, data frame definitions, message definitions, and dialogs. Volume III contains extensible markup language (XML) schema for encoding data elements and messages in a well-understood format. Volume IV contains annexes addressing several topics including mapping TCIP to the National Architecture, ASN.1 data types used in TCIP, narrow band encoding, polling protocol, and procurement compliance documents.
This module will provide the basic knowledge allowing transit agency staff and vendors to begin the process of applying a standards-based framework for procurement and deployment of ITS systems to better manage transit agency operations and assets, and to better serve customers.
The second of the two TCIP course modules (TCIP 2) describes the suite of tools provided to make the standard accessible to users. It focuses on how to access TCIP using the TCIP Implementation Requirements and Capabilities Editor (TIRCE), and shows case studies that illustrate how TCIP and the suite of tools can be used in procuring ITS systems for a transit agency.
Examples and Real World Applications
Current TCIP Projects
Concept of Operations - Distributing Scheduling Products
(Extended Text Description: Who is using TCIP? Examples and Real World Applications – Lynx Pilot This slide shows a snapshot of the FUTURE LYNX (Orlando) Agency ITS Architecture. Non-TCIP interfaces are shown by black lines connecting the boxes. TCIP interfaces are shown by red lines. Descriptions for non-generic boxes in the LYNX Architecture Trapeze Scheduling is a Transit Schedule Development Platform. This system provides data to Trapeze BD and to aE Schedule Translation which uses TCIP to interface with aE Traveler Information/AVL, aE Advertising Manager and aE VLU Trapeze BD Transportation Operations provides bid processing, dispatch control, and timekeeping and sends data to Mentor CAD Mentor AVL provides near-real time bus tracking data to Mentor CAD and to aE Traveler Information/AVL Mentor CADD provides computer assisted management of buses while they are en route as well as for initial dispatch. LYNX Bus to Blocks is a LYNX IT Application that manages the daily assignment of buses to blocks (work assignments) which also provides information to aE Traveler Information/AVL Ontira Trip Planner provides customers with address-to-address trip planning by combining a routing algorithm with dynamic mapping and provides data to Ontira Multimedia which provides customers with service information via a variety of communications media (phones, internet, kiosks, etc.).)
This slide shows a snapshot of the FUTURE LYNX (Orlando) Agency ITS Architecture. TCIP interfaces are shown by red lines.
Descriptions for non-generic boxes in the LYNX Architecture
(Extended Text Description: Who is using TCIP? Examples and Real World Applications (cont.) – Author’s relevant notes, for illustration purposes only: King County Transit ITS Architecture This graphic shows the King County Metro architecture for Transit Signal Priority. TCIP will be used to communicate information that supports signal priority requests from buses to the traffic signal control system. The TCIP compliant interface is shown as a red line. The conversation between the Priority Request Generator (PRG) and the Priority Request Server (PRS) uses a different standard.)
This graphic shows the King County Metro architecture for Transit Signal Priority. TCIP will be used to communicate information that supports signal priority requests from buses to the traffic signal control system. The TCIP compliant interface is shown as a red line. The conversation between the Priority Request Generator (PRG) and the Priority Request Server (PRS) uses a different standard.
(Extended Text Description: Who is using TCIP? Examples and Real World Applications (cont.) – MTA Bus Time Technology – MTA Bus CIS Concept Architecture This graphic illustrates the New York MTA’s bus customer information system architecture. TCIP is used in conjunction with other standards to communicate real time bus arrival data every 30 seconds from 5,500 buses to the central server. On the left are shown components on a bus, including the Operator Login Information which is sent to the Payment Terminal. An enhanced GPS unit provides NEMA standard location data to the Payment Terminal which then sends location and login data from the bus to a 3G modem. The Verizon wireless data network sends the data which uses standards including TCIP, JSON and HTTP to the CIS server in the MTA back office. Here, GTFS standard is used to send Schedules, Map and Route Data to the Bus CIS Server. TCIP is used to send crew dispatch data to the Bus CIS Server. The Bus CIS Server uses SMS to send information to customer cell phones, and uses the web to send data to smart phones, customer PC’s, and digital displays.)
This graphic illustrates the New York MTA’s bus customer information system architecture. TCIP is used in conjunction with other standards to communicate real time bus arrival data every 30 seconds from 5,500 buses to the central server.
(Extended Text Description: Who is using TCIP? Examples and Real World Applications (cont.) AMT Montreal - This graphic illustrates how Montreal’s Agence Métropolitaine de Transport (AMT) uses TCIP dialogs to exchange data between two different CAD/AVL servers. A CAD/AVL Server for AMT is shown as a circle on the left. This exchanges data over a communications stack depicted as a triangle in the middle. On the right, a circle represents the CAD/AVL server for a sister agency, STL. The triangle segments in the middle illustrate the communication layers involved the exchange. Ethernet protocols are the bottom layer. TCIP is the next layer which is used to specify the dialogs. The messages in the dialogs are encoded in XML using the TCIP schema shown as the top layer.)
This graphic illustrates how Montreal’s Agence Metropolitaine de Transport (AMT) uses TCIP dialogs to exchange data between two different CAD/AVL servers.
The green triangle segments in the middle illustrate the communication layers involved the exchange. Ethernet protocols are the bottom layer. TCIP is the next layer which is used to specify the dialogs. The messages in the dialogs are encoded in XML using the TCIP schema.
(Extended Text Description: This graphic illustrates the architecture used by AMT, showing where the TCIP dialogs fit in the communication layers. Icons representing two groups of servers on each end of the graphic are separated by and connected to firewalls and the physical layer of a network, represented by a cloud. The physical layer points up to two green boxes inside a larger box labeled "Protocols used". The topmost box is labeled "Applications Protocol - SOAP". The lower box is labeled Transport protocol - TCP/IP".)
This graphic illustrates the architecture used by AMT, showing where the TCIP dialogs fit in the communications layers, and other supporting layers and standards.
Example - Concept of Operations
(Extended Text Description: TCIP Standard Volume I Section 22.214.171.124 Distributing Scheduling Products (continued) – This slide shows an oval in the center representing the data repository connected by arrows denoting data flows to eleven other ovals representing various business systems that need to receive scheduling products, including: Transit Security System, Garage Server, Geographic Information System, Traveler Information System, Customer Service System, Operator Assignment System, External Agency, Passenger Counting System, CAD/AVL System, Asset Management System, and other Authorized Business System.)
The graphic shows the concept of operations diagram for how scheduling products would be distributed to other business systems in the transit agency from a data repository
The graphic on this slide illustrates the Data Repository sending schedule information (that it received from the Scheduling System) to other associated units. If an agency does not have a Data Repository, the Scheduling System can directly send the schedule information to the associated units.
(Extended Text Description: This diagram is labeled "126.96.36.199 - Distributing Scheduling Products". Below that there are two circles connected by a line. The circle on the left is labeled "Scheduling System". The line is labeled "A, B, 1". The circle on the right is labeled "Data Repository". Beneath those circles are three boxes. The box labeled A contains the following text:
The box labeled B contains the following text:
The box labeled I contains the following text:
The graphic replicates a portion of the concept of operations diagram showing how scheduling system products are distributed to a data repository. New schedules are generated by scheduling system software. They are then distributed to a data repository where they can be stored and distributed to other business systems.
For this example, we will focus on the sub-process of "Distributing scheduling products" (i.e., 188.8.131.52 in the TCIP Standard Volume 1). In this case, the Scheduling System is sending the schedule data to the Data Repository.
"A" = Schedule product distributed via a "publish-subscribe" dialog "B" = Schedule product distributed via a "push" to all receivers dialog "1" = Schedule product distributed via a file transfer
3. Case Study
The following case study illustrates the development of an agency architecture as new ITS systems are added over a five year period.
Current Agency ITS Architecture and Operations shown in Figure 1
A public referendum was voted on, that resulted in 0.5% of the local sales tax being dedicated to use for transit improvements. The agency was tasked by the Metropolitan Planning Organization (MPO) to develop a plan to upgrade the Agency’s Systems to improve the quantity and quality of information provided to the public, and to improve operational efficiency. After some internal planning and debate, the agency developed a set of 3 and 5 year goals for upgrades to its business systems and these were approved by the MPO.
The agency’s goals for the first 3 years are to implement:
Within 5 years, the agency’s goals are to implement:
The three following figures show: 1) the baseline architecture, 2) the year three architecture, and 3) year five architecture.
(Extended Text Description: Diagramming an agency architecture This figure illustrates an agency architecture diagram showing a base year configuration of systems on the bus and in the management center. Boxes represent various systems and lines with arrows show the data flows among the systems. A pick system*, a scheduling system and a bus manager system all interface with the agency database using TCP/IP internet type connections. On the bus, a head sign controller and the drive train computers operate independently. A Fare Mobile Data Terminal on the bus has a wired connection to the farebox computer. The farebox computer can exchange data with a central fare server at the garage using an infra-red connection. The agency has plans to add additional functionality in year 3 of their ITS capital program and how the architecture changes will be seen in the next slide. *A "pick" system is one that is used for drivers to choose work assignments. Some agencies refer to these systems as "sign-up" systems or use other names.)
Figure 1 Current Agency Architecture and Legacy Systems
(Extended Text Description: Diagramming an agency architecture (continued) Year 3 Architecture - This slide is to be compared with the previous one to show the second stage of implementation for the agency’s ITS architecture. Boxes represent various systems and lines with arrows show the data flows among the systems. In year 3, the agency intends to add: an itinerary planner that directly feeds customers via the internet, an announcement recording studio system, an automatic vehicle stop annunciation system, a vehicle location system, and an automatic vehicle health monitoring system These systems will require more integration with other systems and the architecture has added lines representing additional data communication flows. Data flows between the bus and the management center now will use wireless local area networks.)
Figure 2 Year 3 Architecture showing:
(Extended Text Description: Diagramming an agency architecture (continued) - Year 5 Architecture The year 5 architecture adds long range wireless data communications between the vehicle and the management center. Additional boxes representing systems and lines representing data flows are added. On board the bus, the vehicle location system, which had been used in year 3 only to drive an automatic stop annunciator system, now has its location data sent via the stop annunciator to the vehicle logic unit, which allows the bus location to be transmitted back to a computer aided dispatch/automatic vehicle location (CAD/AVL) system. The CAD/AVL system now sends data to a Traveler Information System which in turn feeds data to Electronic Bus Stop Sign Displays.)
Figure 3 showing the year 5 architecture with the following new systems:
|Agency ITS Architecture||The repository for capturing and documenting the agency’s legacy and planned business systems, legacy interfaces, as well as the TCIP interfaces. The agency ITS architecture may specify a series of development phases for the agency’s ITS systems|
|Agency Specification||A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency.|
|APTA||American Public Transportation Association. Serves and leads its diverse membership through advocacy, innovation, and information sharing to strengthen and expand public transportation|
|Compliance||A condition that exists when an item meets all of the requirements of an agency specification.|
|Concept of Operations||A document that describes the purpose for a system project, including a description of the current and proposed system, as well as key user needs that the new system is required to address.|
|Conformance||A condition that exists when an item meets all of the mandatory requirements as defined by a standard. It can be measured on the standard as a whole, which means that it meets all mandatory (and applicable conditional) requirements of the standard or on a feature level (i.e., it conforms to feature X as defined in section X.X.X), which means that it meets all mandatory (and applicable conditional) requirements of the feature.|
|Data element||An atomic piece of information related to a person, place, thing, or concept. For example, CPT-PersonFirstName and CPT-Footnote are data elements|
|Data frame||A grouping of data elements primarily for the purpose of referring to a group with a single name, and thereby efficiently reusing groups of data elements that commonly appear together (as an ASN.1 Sequence, Sequence Of , or Choice) in a TCIP message. This data concept type may also be used to specify groups of data elements for other purposes as well. A data frame may contain other data frames as well as data elements.|
|Data repository||A business system in a transportation organization, whose primary function is to accept and store agency data, which may include the output of other business systems, and to make the data available to authorized business systems on demand. Some repositories may combine data from different business systems and provide the results on request, or may process the data and provide the processed result to authorized business systems.|
|Dialog||An ordered sequence of message exchanges between two or more entities. The rules of the exchange are defined by a dialog pattern. Messages specific to the type of exchange are specified by the dialog.|
|Dialog Pattern||A description of a message exchange between two or more entities, including the rules associated with the exchange. Generally, the same pattern can be used to convey more than one type of information. For example, a Publication could convey schedules or alarm information.|
|File Transfer||An information transfer effected between two computers by having one computer write information to a file, moving the file to the other computer and, having the second computer read the file. In the case of a TCIP file transfer, the file is an XML document consisting of a single TCIP message.|
|Interface||The point of interaction between a business system, subsystem, or component, and any other entity.|
|LRMS||Location Referencing Message Specification. SAE Standard J2266. Standardizes location referencing for ITS applications that require the communication of spatial data references between databases or computer applications.|
|Message||A grouping of data elements and/or data frames intended to be transmitted as a complete package of information in one direction.|
|Model architecture||A generic representation to illustrate the range of intelligent transportation systems and interfaces within a transit agency as well as the interfaces between the agency and other agencies and/or private entities|
|National ITS Architecture||Provides a common framework for planning, defining, and integrating intelligent transportation systems|
|Profile Implementation Conformance Statement (PICS)||A document used to specify the TCIP interface(s) associated with an implementation. The PICS lists the TCIP dialogs, TCIP message file transfers, and options supported by the implementation along with other detailed information about the interface.|
|Profile Requirements List (PRL)||A document used to specify an agency’s requirements for the TCIP interface(s) associated with a new or upgraded system. The PRL lists the TCIP dialogs, TCIP message file transfers, and options required for the interface along with other detailed interface information.|
|Regional ITS architecture||A common framework for planning, defining, and integrating intelligent transportation systems within a metropolitan region|
|Scheduling system||A business system that creates transit schedules and organizes planned trips within that schedule into operator and vehicle assignments.|
|Timepoint||A point along a public transit vehicle’s route where the vehicle’s scheduled time to traverse that point is identified in the schedule. Timepoints may be defined and not used in the schedule, or may be used in more than one route.|
|Transit business system||A fixed computer application within the Model Architecture that performs a particular business function or group of related functions.|
|TCIP Implementation & Requirements Capabilities Editor (TIRCE)||A software application to document agency requirements and specifications for TCIP interfaces, vendor product capabilities, and allow the capabilities to be compared with the requirements|
|Transit signal priority||A TCIP business area related to obtaining preferential treatment for public transit vehicles at signalized intersections.|
"NTI Instructor Materials: Integrating Transit Applications: Defining Data Interfaces Using TCIP," Power Point Presentation, NTI, February, 2012
J. Fayos, draft "NTI Instructor Materials: Integrating Transit Applications: Defining Data Interfaces Using TCIP," NTI, August, 2013
Figure 9.2 "TCIP Provides the Building Blocks for Agency ITS architectures and RFPs," APTA TCIP-S-001 4.0.0 Volume I, p 328,
Concept of operations - Wikipedia, the free encyclopedia, accessed July 12, 2014 https://www.google.com/search?q=definition+concept+of+operations&rlz=1C1LDJZ_enUS499US518&oq=definition+concept+of+&aqs=chrome.1.69i57j0l5.7685j0j8&sourceid=chrome&es_sm=122&ie=UTF-8
ITS PCB T3 Webinars on ITS Transit Standards http://www.pcb.its.dot.gov/t3_archives.aspx
"Integrating Transit Applications: Defining Data Interface Requirements Using TCIP - Participant Workbook" Accessed September 23, 2014
6. Study Questions