An Overview
Transit Communications Interface Protocols (TCIP)
White Paper 1
Prepared by
Paula Okunieff
Tom Buffkin
Xudong Jia
Karen Levine
Cambridge Systematics, Inc.
Eva Lerner-Lam
Palisades Consulting Group, Inc.
Isaac Takyi
New York City Transit Authority
February 24, 1997
1.0 Introduction
Transit operators face problems in today Information Age. The challenges are the same
whether operators are designing a trip itinerary for a customer using real-time
information, making service changes based automated passenger counters and AVLcollected travel times, or modifying fare structures based on actual passenger travel
distance and transfer data.
Chances are, once operators overcome institutional and budget obstacles, they come up
against data problems: Data kept by the Planning department is in one format,
maintained in a different format by the Maintenance department, and in yet another
format by the Dispatch and Transit Information Centers. Data incompatibility has been
the stumbling block for many Advanced Transportation Public Systems projects.
The Transit Communications Interface Protocols (TCIP) effort will define data interfaces
that will allow data to flow among departments, and between and among applications
and other external entities such as traffic management centers and emergency
management centers.
2.0 Project Plan
The TCIP was initiated in November, 1996. Funded by the U.S. Department of
Transportation Joint Program Office for Intelligent Transportation Systems, and
developed by the Institute for Transportation Engineers (ITE), the TCIP effort is a oneyear standards development effort designed to provide the interface structures that will
allow disparate transit components and organizations to exchange data.
As specified in the Project Plan:
T]he project will define the information and information transfer requirements among
public transportation vehicles, the Transit Management Center, other transit facilities, and
other ITS centers; develop physical and data link requirements; develop required message
sets; and establish liaison and coordinate between ITE and other Standard Development
Organizations (SDOs) on the development of related standards.”
The project will provide the leadership to coordinate, develop, and deploy a
comprehensive set of transit communication interface protocols (TCIP) that allows
effective and efficient exchange of data used for ITS user services and transit operations,
maintenance, customer information, planning and management functions. The scope
provides for interfaces among transit applications to communicate data among transit
departments, other operating entities such as emergency response services and regional
traffic management centers.”
-1-
The results of this effort will be to a set of provisional standards for TCIP” [Project Plan,
August 29, 1997, page 1]
The ambitious schedule will be coordinated with the TCIP Technical Working Group
(TWG) to ensure industry review at every stage. A Leadership Summit will be held on
February 27 and 28, 1997 to develop data flow definitions and functional interchange
requirements. Between March and September 1997, the TCIP technical team will develop
the object and message sets for designated interfaces. This work will be reviewed by the
TWG to ensure appropriateness and usability by 揵uyers” and 搒ellers” of transit systems.
After consensus is achieved (hopefully by early January 1998), the provisional standard
will be put up to a vote by ITE.
3.0 National Transportation Communications for ITS
Protocol (NTCIP) Overview
The National Transportation Communication for ITS Protocol (NTCIP), initiated in 1992
by the National Electrical Manufacturers Association (NEMA), undertook a task to
develop a common interface for traffic field devices. In 1995, the Federal Highway
Administration recommended broadening the scope to include systems supported by the
National ITS System Architecture. In particular, the NTCIP scope was expanded to
ensure that different devices were interoperable and similar devices manufactured by
different vendors were interchangeable on the same communication infrastructure.
[NTCIP Steering Group, The National Transportation Communications/ITS Protocol: An
Introduction.” ITE Journal, December 1995. pp. 36-40.]
To achieve these goals, the protocol was based on the International Standards
Organization (ISO) Open System Interconnet (OSI) Reference Model. The model is based
on seven layers each of which provide distinct services. Table 3.1 describes the services
provided for each layer.
Because the model is modular and layers are functionally independent, specific protocols
at each layer may be interchanged with other industry standards protocols that provide
similar services yet supports different communications architectures. The NTCIP in
applying international standard protocols is defining a profile.” A profile can be tailored
to meet the requirements of the system. NTCIP currently specifies three profiles (see
Table 3.2).
-2-
Table 3.1 ISO OSI Reference Model
Application:
Provides access to the OSI environment for users and also provides
distributed information services.
Presentation:
Provides independence to the application processes from differences in data
representation (syntax).
Session:
Provides the control structure for communication between applications;
establishes, manages, and terminates connections (sessions) between
cooperating applications.
Transport:
Provides reliable, transparent transfer of data between endpoints; provides
end-to-end error recovery and flow control.
Network:
Provides upper layers with independence from the data transmission and
switching technologies used to connect systems; responsible for establishing,
maintaining, and terminating connections.
Data Link:
Provides for reliable transfer of information across the physical link; sends
blocks of data (frames) with the necessary synchronization, error control, and
flow control.
Physical:
Concerned with transmission of unstructured bit stream over physical
medium; deals with the mechanical, electrical, functional, and procedural
characteristics to access the physical medium.
Source:
Stallings, William, Data and Computer Communications. MacMillan Publishing Company,
New York, New York, 1985, p. 388.
-3-
Table 3.2 NTCIP Class Profiles
Layer
Class-A
Class-B
Class-C
Application
7
SNMP/STMP
SNMP/STMP
SNMP/STMP
Presentation
6
null
null
null
Session
5
null
null
null
Transport
4
UDP
null
TCP/UDP
Network
3
IP
null
IP
Data Link
2
Async HDLC
Async HDLC
Async HDLC
Physical
1
EIA/TIA 232
EIA/TIA 232
EIA/TIA 232
Source:
NEMA TS 3.1-1996, page 23.
NTCIP subcommittees are discussing developing additional profiles which use other
protocols (such as Remote Procedure Calls (RPC) to meet specific user requirements.
Profile specification is not within the scope of TCIP. However, if as a result of specifying
technology requirements the community identifies specific communication needs not
supported by existing NTCIP profiles, we may develop some profiles, if so recommended
by the TCIP Technical Working Group. For example, many transit agencies are installing
automatic vehicle identification (AVI) devices for tracking vehicles entering and leaving
garage facilities, signpost-AVL or uploading/downloading vehicle performance data.
This wireless Dedicated Short Range Communication (DSRC) protocol is not currently
supported by NTCIP, neither are other wireless communication methods. Additional
profiles which support these communication technologies will be recommended as part of
this effort. Many of the communication media are identified by the System Architecture;
the TCIP project team will extract more detailed requirements for these interfaces.
Most importantly for TCIP, NTCIP adopted the Abstract Syntax Notation (ASN.1) (ISO
IEC 8824) to specify domain data. The ISO Technical Committee 204 (TC204) Working
Group 1 (WG1), which deals with ITS systems and architectural issues, proposed use of
ASN.1 to specify data interchange structures. TCIP use of ASN.1 to specify the data will
be wholly consistent with national and international standards efforts.
ASN.1 specifies a set of rules and procedures for structuring and addressing data. ASN.1
is built in a tree-structure, similar to the addressing scheme used on the internet (see
Figure 3.1). This provides for an efficient way to uniquely and unambiguously identify
data. The lowest level is referred to as a data primitive. In ASN.1 terminology this level
presents objects. The levels above represent the object sets (because they include multiple
objects). Object sets group data into classes. These classes may provide efficient coding
structures or may decrease coding complexity.
For that reason, an important
consideration for this project is to describe a clear and representative classification
scheme.
-4-
Figure 3.1 Internet Authority Hierarchical
ROOT
CCITT
O
Standard
0
ISO
1
Reg Autho rity
1
Member Body
2
ISO-CCITT
2
Organization
3
Country
16
DOD
6
USA
640
Internet
1
Organization
1
Private
4
Enterprises
1
(Other
Companies)
1 .. .N
NEMA
1206
(Other
Countries)
1 .. .N
Source: Adapted from NEMA TS 3.1-1996, page. 33.
4.0 TCIP Methodology
Since the focus of our effort will be on developing application layer specifications, we
adapted a conventional methodology recommended by the ISO OSI Reference Model.
This four step process generates increasing levels of detail of data interaction and flow.
The process is very similar to a top-down/functional decomposition methodology used
for developing large information technology (IT) systems. The steps include the
definition of the conceptual overview of the system; detailed design of the interactions
and further functional decomposition; definition of the interactions, classification of the
data and development of the data structures; and finally descriptions of the rules and
procedures governing the interactions.

系统整体概念定义;

关于系统相互关联的详细设计及前瞻性功能分解;

接口定义、数据分类及发展性的数据结构；

在交互过程中的规则及过程管理。
-5-
 4.1 System Overview
Much of the system overview was developed by the ITS System Architecture study. The
National System Architecture study sponsored by the JPO/ITS [reference] described the
systems, subsystems and component and many of the interactions between transit
management and other ITS systems. The types of data, flows, media and other
requirements are outlined in the collection of 18 (?) documents. In addition, Sandia
National Laboratory, sponsored by the FTA, developed an APTS System Architecture
which describes many of the flows among transit departments, systems and subsystems
within the transit agency. These materials provide a substantial overview of the
APTS/transit framework.
Figure 4.1 represents an overview of the APTS System Architecture. This model shows
both internal and external interactions. A shaded box indicates that the center or
subsystem may be part of a transit agency. For example, the larger transit agencies
support parking facilities, police and emergency management functions, traveler
information systems, and roadways and access facilities. The shaded boxes do not
preclude transit systems from sharing information with Information Service Providers
(ISP), other Planning Systems, Emergency Management Centers, etc. In fact, this
architecture shows that much of the information that is exchanged within a transit agency
overlaps with external data exchange requirements.
 4.2 Data Interaction Design
This step is also called the Conceptual Schema Development. During this phase, the
System Architecture is decomposed into components, inputs and outputs. The system
architecture is analyzed to a more detailed level of interactions. Whereas the system
architecture dealt with systems and subsystems, the conceptual schema deals with
components and their interaction and data flows. The definition of component may differ
for various system implementations. The level of detail needs to meet the level of
component interoperability. For example, the Transit Management System (TrMS) may
be composed of multiple systems including 1)Onboard, 2)Radio, 3)Communications
control, 4)Computer aided dispatch; or it may be a single turnkey system. In the former
case, the TrMS requires at least ten interfaces (see Figure 4.2a); in the latter case, the
system only requires two interfaces (see Figure 4.2b).
The definition and detailed description of these interfaces are essential to developing
useful and robust TCIP specifications. The objective of the Leadership Summit is to fully
describe these interfaces and associated information. A conceptual schema is composed
of the data flows between components, specifically, the components must be described
and understood, and input and output data defined, including format, range of values,
units and other constraints. When all the data flows are compiled and synthesized the
result is a data flow diagram, data dictionary and set-use table.
Because a core set of data flows among many components, the relationship among the
data is significant. The European Community, in developing the Reference Data Model
for Public Transport (hereafter referred to as TRANSMODEL) [CEN TC278/ WG3]
documented those relationships and developed a comprehensive glossary of terms. The
-6-
components outlined by TRANSMODEL include: Scheduling, Personnel Disposition,
AVM, Passenger Information, Fare Collection, Management Information and Geographic
Data. Both the components and terms will be used as a starting point for the
development of the Conceptual Schema products.
-7-
Figure 4.1 APTS System Architecture
PAIS
Personal
Information
Access
Parking
Service
Provider
PMS
RTS
Parking
Management
Remote Traveler
Support
Intermodal
Transportation
Planners
Transportation
Service Provider
PS
PS
Planning
Subsystem
ISP
Financial
Institution
TMS
Government
Administrators
Traffic
Management
Information
Service
Provider
EM
EMVS
Emergency
Emergency
Management
Vehicle
Subsystem
TRMS
RS
Transit
Roadway
Subsystem
Management
TRVS
Multimodal
Crossing
Transit Vehicle
Subsystem
Transit Vehicle
Other TRM
(J1708/J1587)
Tr GMS
Transit Garage
Management
System
Recommended by Transit
Source: Extracted from the National ITS System Architecture.
-8-
Figure 4.2a Component Level Flow Diagram for AVL
Scheduling
On-Board
Processor/
Radio
Communication
Sy stem
Control
Sy stem
DBMS
Server/
Operator/
Roster
Reports
Base Map
GIS
Route
Bus Stop
Time Po int
Figure 4.2b Turnkey Flow Diagram for AVL
 4.3 Object Set Definition
The focus of this effort is on defining the objects that compose the object sets. Grouping
the data into logical categories to avoid redundancies while associating object sets with
specific interfaces may not be possible. For example, an object such as time point, which
flows among many transit components and external interfaces, would require definition
in all the object sets associated with the components setting or using a time point. Yet,
declaring a time point as global to all functions is not considered good programming
practice nor is it required by all components. As demonstrated by TRANSMODEL and
the APTS Map Database User Requirements Document, transit data may be classified into
under twenty seven categories [MDURD, p. 29-33] and about 440 terms [TRANSMODEL,
Vol. 3, pp. 11-54]. For that reason, classifying the data according to type may prove to be
the best alternative. Following classification of the object sets, we will correlate each term
with the appropriate object set. Definition, range of value, unit and use were already
defined as part of the conceptual schema phase.
-9-
 4.4 Rules and Procedures
The rules and procedures phase is equivalent to defining the NTCIP profiles. The TCIP
project will not define a profile. However, it will examine interface requirements,
recommend existing profiles or identify the need for alternative profiles. As part of this
effort, we will track other communication protocol standards activities, such as Dedicated
Short Range Communications (DSRC) and digital radio communications.
Standard Development Process
This development effort supports the TCIP Technical Working Group (TWG), sponsored
by ITE and composed of industry experts. As an industry standard organization, the
TCIP TWG will review technical products and specifications developed by the TCIP
project team and recommend changes. After approval of the first draft, the TWG will be
responsible for managing the products in a standards development process. The TCIP
project team will continue to provide technical and logistical support to the group within
the scope of their contract.
The TWG structure and membership meet ANSI and ITE guidelines; only members can
vote; membership will be balanced among vendors, users and other interested parties;
each organization is allowed only one member (this requirement may be relaxed to
achieve a balance among vendors, users and other interested parties); and participation is
open to all.
White papers which discuss complex and controversial issues will be published and
disseminated to promote discussion in the industry. These papers highlight technical
difficulties, discuss alternatives, and recommend approaches to dealing with major issues.
The white papers will be made available on the TCIP home page (www.tcip.org) and in
hard copy to those without Internet access. Comments submitted by TWG participants
and others will be posted on an interactive discussion group. (The discussion group will
be moderated.) TWG generated minutes and white papers will also be posted on the
home page for downloading and discussion. Also, upcoming meetings and other TCIPrelated news will be accessible through the home page. TWG and TCIP project team
members may be contacted through the web site, as well.
For more information on the TCIP Project contact Eva Lerner-Lam, Project Director, Palisades
Consulting Group at (201) 567-0088, or Paula Okunieff, Technical Project Manager, Cambridge
Systematics at (617) 354-0167. For information on the Technical Working Group contact Isaac
Takyi, TCIP TWG Chairman, New York City Transit Authority at (718) 694-3652.
- 10 -