Recommended Standard of NTCIP 1209 v02.17 - Institute of ...

A Recommended Standard of the Joint Committee on the NTCIP 

NTCIP 1209 version v02.17 

National Transportation 

Communications for ITS Protocol 

Object Definitions for 

Transportation Sensor Systems (TSS) 

v02.17 December 2010 

This is a draft pre-standard document, which is distributed for review and ballot purposes 

only. You may reproduce and distribute this document within your organization, but only 

for the purposes of and only to the extent necessary to facilitate review and ballot to 

AASHTO, ITE, or NEMA. Please ensure that all copies include this notice. This prestandard 

contains recommended information that is subject to approval. Use this 

information at your own risk. 

Published by 

American Association of State Highway and Transportation Officials (AASHTO) 

444 North Capitol Street, N.W., Suite 249 

Washington, D.C. 20001 

Institute of Transportation Engineers (ITE) 

1627 I (“Eye”) Street, N.W., Suite 600 

Washington, D.C. 20006 

National Electrical Manufacturers Association (NEMA) 

1300 North 17th Street, Suite 1752 

Rosslyn, Virginia 22209-3801 

© 2010 AASHTO / ITE / NEMA. All rights reserved. 

filename 1209v0217b RS.doc

NOTICES 

Copyright Notice 

NTCIP 1209 v01 © 2005, and NTCIP 1209 v02 © 2010, by the American Association of State Highway 

and Transportation Officials (AASHTO), the Institute of Transportation Engineers (ITE), and the National 

Electrical Manufacturers Association (NEMA). All intellectual property rights, including, but not limited to, 

the rights of reproduction, translation, and display are reserved under the laws of the United States of 

America, the Universal Copyright Convention, the Berne Convention, and the International and Pan 

American Copyright Conventions. Except as licensed or permitted, you may not copy these materials 

without prior written permission from AASHTO, ITE, or NEMA. Use of these materials does not give you 

any rights of ownership or claim of copyright in or to these materials. 

Visit www.ntcip.org for other copyright information, for instructions to request reprints of excerpts, and to 

request reproduction that is not granted below. 

PDF File License Agreement 

To the extent that these materials are distributed by AASHTO / ITE / NEMA in the form of an Adobe® 

Portable Document Format (PDF) electronic data file (the “PDF file”), AASHTO / ITE / NEMA authorizes 

each registered PDF file user to view, download, copy, or print the PDF file available from the authorized 

Web site, subject to the terms and conditions of this license agreement: 

a) you may download one copy of each PDF file for personal, noncommercial, and intraorganizational 

use only; 

b) ownership of the PDF file is not transferred to you; you are licensed to use the PDF file; 

c) you may make one more electronic copy of the PDF file, such as to a second hard drive or burn to a 

CD; 

d) you agree not to copy, distribute, or transfer the PDF file from that media to any other electronic 

media or device; 

e) you may print one paper copy of the PDF file; 

f) you may make one paper reproduction of the printed copy; 

g) any permitted copies of the PDF file must retain the copyright notice, and any other proprietary 

notices contained in the file; 

h) the PDF file license does not include: 1) resale of the PDF file or copies, 2) republishing the content 

in compendiums or anthologies, 3) publishing excerpts in commercial publications or works for hire, 

4) editing or modification of the PDF file except those portions as permitted, 5) posting on network 

servers or distribution by electronic mail or from electronic storage devices, and 6) translation to other 

languages or conversion to other electronic formats; 

i) other use of the PDF file and printed copy requires express, prior written consent. 

Data Dictionary and MIB Distribution Permission 

To the extent that these materials are distributed by AASHTO / ITE / NEMA in the form of a Data 

Dictionary (“DD”) or Management Information Base (“MIB”), AASHTO / ITE / NEMA extend the following 

permission: 

You may make or distribute unlimited copies, including derivative works, of the DD or MIB, including 

copies for commercial distribution, provided that:

a) each copy you make or distribute contains the citation “Derived from NTCIP 0000 [insert the standard 

number]. Used by permission of AASHTO / ITE / NEMA.”; 

b) the copies or derivative works are not made part of the standards publications or works offered by 

other standards developing organizations or publishers or as works-for-hire not associated with 

commercial hardware or software products intended for field implementation; 

c) use of the DD or MIB is restricted in that the syntax fields may be modified only to reflect a more 

restrictive subrange or enumerated values; 

d) the description field may be modified but only to the extent that: 1) only those bit values or 

enumerated values that are supported are listed; and 2) the more restrictive subrange is expressed. 

These materials are delivered “AS IS” without any warranties as to their use or performance. 

AASHTO / ITE / NEMA and their suppliers do not warrant the performance or results you may 

obtain by using these materials. AASHTO / ITE / NEMA and their suppliers make no warranties, 

express or implied, as to noninfringement of third party rights, merchantability, or fitness for any 

particular purpose. In no event will AASHTO / ITE / NEMA or their suppliers be liable to you or any 

third party for any claim or for any consequential, incidental or special damages, including any 

lost profits or lost savings, arising from your reproduction or use of these materials, even if an 

AASHTO / ITE / NEMA representative has been advised of the possibility of such damages. 

Some states or jurisdictions do not allow the exclusion or limitation of incidental, consequential, or special 

damages, or the exclusion of implied warranties, so the above limitations may not apply to a given user. 

Use of these materials does not constitute an endorsement or affiliation by or between AASHTO, ITE, or 

NEMA and the user, the user’s company, or the products and services of the user’s company. 

If the user is unwilling to accept the foregoing restrictions, he or she should immediately return these 

materials. 

PRL and RTM Distribution Permission 

To the extent that these materials are distributed by AASHTO / ITE / NEMA in the form of a Profile 

Requirements List (“PRL”) or a Requirements Traceability Matrix (“RTM”), AASHTO / ITE / NEMA extend 

the following permission: 

a) you may make or distribute unlimited copies, including derivative works of the PRL (then known as a 

Profile Implementation Conformance Statement (“PICS”)) or the RTM, provided that each copy you 

make or distribute contains the citation “Based on NTCIP 0000 [insert the standard number] PRL or 

RTM. Used by permission. Original text © AASHTO / ITE / NEMA.”; 

b) you may only modify the PRL or the RTM by adding: 1) text in the Project Requirements column, 

which is the only column that may be modified to show a product’s implementation or the projectspecific 

requirements; and/or 2) additional table columns or table rows that are clearly labeled as 

ADDITIONAL for project-unique or vendor-unique features; and 

c) if the PRL or RTM excerpt is made from an unapproved draft, add to the citation “PRL (or RTM) 

excerpted from a draft standard containing preliminary information that is subject to change.” 

This limited permission does not include reuse in works offered by other standards developing 

organizations or publishers, and does not include reuse in works-for-hire, compendiums, or electronic 

storage devices that are not associated with procurement documents, or commercial hardware, or 

commercial software products intended for field installation. 

A PICS is a Profile Requirements List that is completed to indicate the features that are supported in an 

implementation. Visit www.ntcip.org for information on electronic copies of the MIBs, PRLs, and RTMs.

Content and Liability Disclaimer 

The information in this publication was considered technically sound by the consensus of persons 

engaged in the development and approval of the document at the time it was developed. Consensus 

does not necessarily mean that there is unanimous agreement among every person participating in the 

development of this document. 

AASHTO, ITE, and NEMA standards and guideline publications, of which the document contained herein 

is one, are developed through a voluntary consensus standards development process. This process 

brings together volunteers and/or seeks out the views of persons who have an interest in the topic 

covered by this publication. While AASHTO, ITE, and NEMA administer the process and establish rules 

to promote fairness in the development of consensus, they do not write the document and they do not 

independently test, evaluate, or verify the accuracy or completeness of any information or the soundness 

of any judgments contained in their standards and guideline publications. 

AASHTO, ITE, and NEMA disclaim liability for any personal injury, property, or other damages of any 

nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly 

resulting from the publication, use of, application, or reliance on this document. AASHTO, ITE, and NEMA 

disclaim and make no guaranty or warranty, express or implied, as to the accuracy or completeness of 

any information published herein, and disclaims and makes no warranty that the information in this 

document will fulfill any of your particular purposes or needs. AASHTO, ITE, and NEMA do not undertake 

to guarantee the performance of any individual manufacturer or seller’s products or services by virtue of 

this standard or guide. 

In publishing and making this document available, AASHTO, ITE, and NEMA are not undertaking to 

render professional or other services for or on behalf of any person or entity, nor are AASHTO, ITE, and 

NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this 

document should rely on his or her own independent judgment or, as appropriate, seek the advice of a 

competent professional in determining the exercise of reasonable care in any given circumstances. 

Information and other standards on the topic covered by this publication may be available from other 

sources, which the user may wish to consult for additional views or information not covered by this 

publication. 

AASHTO, ITE, and NEMA have no power, nor do they undertake to police or enforce compliance with the 

contents of this document. AASHTO, ITE, and NEMA do not certify, test, or inspect products, designs, or 

installations for safety or health purposes. Any certification or other statement of compliance with any 

health or safety-related information in this document shall not be attributable to AASHTO, ITE, or NEMA 

and is solely the responsibility of the certifier or maker of the statement. 

Trademark Notice 

NTCIP is a trademark of AASHTO / ITE / NEMA. All other marks mentioned in this standard are the 

trademarks of their respective owners.

NR Reference Status Tracking 

(to be deleted on publication) 

Reference 

Designation 

Title 

Type 

(Norm, 

Other) 

Status 

1103 v02 TMP Norm. Changed refs to 1103 v02. Apr 2009 = 

edited and RS sent to SDO ballot. June 

2010 = JA. Oct 2010 = published. 

1201 v03 GO Norm. 1209 v02 needs 1201 v03. Changed refs 

to 1201 v03. May 2010 = repl RS 

accepted by JC. May 2010 = out for SDO 

ballot. Dec 2010 = JA 

2301 v02 AP-STMF Norm. 2008 = RS; 2009 = out for ballot; 2010 = 

JA. Sept 2010 = Published 

8004 v02 SMI Other 2009 = out for ballot; June 2010 = JA; 

Aug 2010 = Published 

Pending 

Off HOLD 

Off HOLD 

May 2010 

Off HOLD 

Off HOLD 

Minor Version Configuration Management [in part, to be deleted on publication] 

minor 

version 

Date & Status 

Editor 

v02.17b RS 12/13-29/2010 pre-ballot consistency edits and PDF Schopp 

nav checking. 

v02.17 RS JJ Review of AG/BS edits, and prep for Next Step Johnson 

v02.16 10/1/2010 edited front matter; checked NRs; Schopp; Goodwin 

Goodwin edits. 

v02.15 4/4/08; post acceptance and edits per JC. Boaz 

v02.14a 3/7/08; pRS

NTCIP 1209 v02.17 

Page i 

ACKNOWLEDGEMENTS 

NTCIP 1209 v02 was prepared by the NTCIP Transportation Sensor Systems (TSS) Working Group, 

which is a subdivision of the Joint Committee on the NTCIP. The Joint Committee on the NTCIP is 

organized under a Memorandum of Understanding among the American Association of State Highway 

and Transportation Officials (AASHTO), the Institute of Transportation Engineers (ITE), and the National 

Electrical Manufacturers Association (NEMA). The Joint Committee on the NTCIP consists of six 

representatives from each of the standards organizations, and provides guidance for NTCIP 

development. 

At the time that NTCIP 1209 v02 was prepared, the following individuals were members of the NTCIP 

TSS Working Group: 

• Ralph Boaz (chair) 

• Terry Haukom 

• Kyle Irvin 

• Allen Jacobs 

• Peter Ragsdale 

• Lynne Randolph 

• Mike Robertson 

• Robert Ung 

• Keith Vennel 

• Jo Versavel 

In addition to the many volunteer efforts, recognition is also given to those organizations that supported 

the efforts of the NTCIP TSS Working Group by providing comments and resources, including: 

• U.S. Department of Transportation, 

Research and Innovative Technology 

Administration, ITS Joint Program Office 

• 3M Intelligent Transportation Systems 

• California Department of Transportation 

• Denver Regional Council of Governments 

• Eberle Design, Inc. 

• Electronic Integrated Systems, Inc. 

• Federal Highway Administration 

• Golden River Traffic, Ltd. 

• Harris County Traffic & Transportation 

Department 

• Image Sensing Systems, Inc. 

• Iteris Roadway Sensors 

• Los Angeles Department of Transportation 

• Minnesota Department of Transportation 

• Noblis 

• Ontario Ministry of Transportation 

• Peek Traffic Corp. 

• Pillar Consulting, Inc. 

• Quixote Traffic Corp. 

• Reno A&E, Inc. 

• Robert De Roche Consulting 

• Sciovid, Inc. 

• Southwest Research Institute 

• Telvent Farradyne Inc. 

• Traficon, Inc. 

• U.S. Traffic Corp. 

© 2010 AASHTO / ITE / NEMA Do Not Copy Without Written Permission


Page ii 

FOREWORD 

NTCIP 1209 v02 defines the Transportation Sensor System (TSS) data elements that are supported by 

the National Transportation Communications for ITS Protocol (NTCIP). A TSS is defined as any system 

capable of detecting and communicating certain traffic parameters using NTCIP. 

The effort to develop NTCIP began with the 3-TS Transportation Management Systems and Associated 

Control Devices Section of the National Electrical Manufacturers Association (NEMA). Their original 

desire was to address a user need for extending the TS 2 standards for traffic control hardware to include 

standardized systems communication. Under the guidance of the Federal Highway Administration's 

(FHWA) NTCIP Steering Group, the NEMA effort was expanded to include the development of 

communications standards for all transportation field devices that could be used in Intelligent 

Transportation Systems (ITS) networks. 

In September 1996, a formal agreement was reached among NEMA, ITE, and AASHTO to jointly 

develop, approve, and maintain NTCIP standards. Under guidance of a Joint AASHTO / ITE / NEMA 

Committee on NTCIP, a Working Group was created to develop data element definitions for Advanced 

Systems Sensors. The first meeting of the Working Group was in August 1997. Discussions within the 

Working Group lead to renaming of the Working Group to Transportation Sensor Systems. 

The predecessor of NTCIP 1209 v02, NTCIP 1209:2005, NTCIP Data Element Definitions for 

Transportation Sensor Systems, defined data elements in ASN.1 using the SNMP Object Type Macro for 

devices that sense the presence or similar characteristics of vehicles. These definitions are intended for 

detection devices that range from smart inductive loop amplifiers to technologies such as machine vision. 

For more information about NTCIP standards, visit the NTCIP Web Site at www.ntcip.org. 

User Comment Instructions 

The term “User Comment” includes any type of written inquiry, comment, question, or proposed revision, 

from an individual person or organization, about any part of this standards publication’s content. A 

“Request for Interpretation” of this standards publication is also classified as a User Comment. User 

Comments are solicited at any time. In preparation of this NTCIP standards publication, input of users 

and other interested parties was sought and evaluated. 

All User Comments will be referred to the committee responsible for developing and/or maintaining this 

standards publication. The committee chairperson, or their designee, may contact the submitter for 

clarification of the User Comment. When the committee chairperson or designee reports the committee’s 

consensus opinion related to the User Comment, that opinion will be forwarded to the submitter. The 

committee chairperson may report that action on the User Comment may be deferred to a future 

committee meeting and/or a future revision of the standards publication. Previous User Comments and 

their disposition may be available for reference and information at www.ntcip.org. 

A User Comment should be submitted to this address: 

NTCIP Coordinator 

National Electrical Manufacturers Association 


Rosslyn, Virginia 22209-3801 

e-mail: ntcip@nema.org 

Do Not Copy Without Written Permission 

© 2010 AASHTO / ITE / NEMA


Page iii 

A User Comment should be submitted in the following form: 

Standards Publication number and version: 

Page: 

Section, Paragraph, or Clause: 

Comment: 

Editorial or Substantive?: 

Suggested Alternative Language: 

Please include your name, organization, and address in your correspondence. 

Approvals 

NTCIP 1209 v02 was separately balloted and approved by AASHTO, ITE, and NEMA after 

recommendation by the Joint Committee on the NTCIP. Each organization has approved this standard as 

the following standard type, as of the date: 

AASHTO—Standard Specification; **** 2011 

ITE—Software Standard; **** 2011 

NEMA—Standard; **** 2011 

History 

A brief history of NTCIP 1209 follows: 

NTCIP 1209:2005 v01.19—Between 1999 and 2002, two user comment drafts were issued for 

review. In 2003, v01.18 was accepted as a Recommended Standard of the Joint Committee. In 

2005, and after disposition of ballot comments, v01.18e was Jointly Approved. In November 

2005, NTCIP 1209 v01.19 was published as NTCIP 1209:2005. 

NTCIP 1209 v02—Between 2004 and 2007, the TSS WG developed drafts with additional 

Systems Engineering content, and support for machine vision detection technology. In August 

2007, the User Comment Draft NTCIP 1209 v02.10 was issued for user review and comment. In 

April 2008, after disposition of user comments, the NTCIP 1209 v02.15 was accepted as a 

Recommended Standard. In October 2010, after lifting a hold imposed by Normative References, 

NTCIP 1209 v02.17 was edited for SDO balloting and approval. In December 2010, v02.17 was 

issued with NTCIP Standards Bulletin B0141. 

Compatibility of Versions 

To distinguish NTCIP 1209 v02 (as published) from previous drafts, NTCIP 1209 v02 also includes 

NTCIP 1209 v02.17 on each page header. All NTCIP Standards Publications have a major and minor 

version number for configuration management. The version number syntax is "v00.00a," with the major 

version number before the period, and the minor version number and edition letter (if any) after the 

period. 

NTCIP 1209 v02 is designated, and should be cited as, NTCIP 1103 v02. Anyone using NTCIP 1103 v02 

should seek information about the version number that is of interest to them in any given circumstance. 

The MIB, the PRL, and the PICS should all reference the version number of the standards publication 

that was the source of the excerpted material. 



Page iv 

Conformant systems based on later, or higher, version numbers MAY NOT be compatible with 

conformant systems based on earlier, or lower, version numbers. Anyone using NTCIP 1209 v02 should 

also consult NTCIP 8004 v02 for specific guidelines on compatibility. 




Page v 

CONTENTS 

Page 

SECTION 1 GENERAL................................................................................................................................. 1 

1.1 Scope......................................................................................................................................... 1 

1.2 References ................................................................................................................................ 1 

1.2.1 Normative References.................................................................................................. 1 

1.2.2 Other References ......................................................................................................... 1 

1.2.3 Contact Information ...................................................................................................... 2 

1.3 General Statements................................................................................................................... 2 

1.4 Terms......................................................................................................................................... 2 

SECTION 2 CONCEPT OF OPERATIONS [NORMATIVE] ........................................................................ 7 

2.1 Tutorial....................................................................................................................................... 7 

2.1.1 Background .................................................................................................................. 8 

2.1.2 Who are You?............................................................................................................... 8 

2.1.3 NTCIP 1209 v02 Organization ..................................................................................... 9 

2.1.4 Sections for Specific Audiences................................................................................... 9 

2.2 Current Situation and Problem Statement................................................................................. 9 

2.3 Reference Physical Architecture ............................................................................................. 10 

2.3.1 Typical Physical Architecture ..................................................................................... 10 

2.3.2 Transportation Sensor Systems (TSS) ...................................................................... 11 

2.3.3 TSS Technologies ...................................................................................................... 11 

2.4 Architectual Needs .................................................................................................................. 12 

2.4.1 Fundamental Needs Driving TSS Deployment .......................................................... 12 

2.4.2 Operational Environment............................................................................................ 12 

2.5 Features................................................................................................................................... 12 

2.5.1 Configure the TSS...................................................................................................... 13 

2.5.2 Control the TSS .......................................................................................................... 15 

2.5.3 Monitor Current TSS Status ....................................................................................... 16 

2.5.4 Collect Data from TSS................................................................................................ 16 

2.5.5 Multi-Version Interoperability (MVI-Backward Compatibility) ..................................... 17 

2.6 Security.................................................................................................................................... 17 

2.7 Operational Policies and Constraints/Assumptions ................................................................ 17 

2.8 Relationship to the National ITS Architecture Flows............................................................... 18 

SECTION 3 FUNCTIONAL REQUIREMENTS [NORMATIVE] ................................................................ 19 

3.1 Tutorial [INFORMATIVE]......................................................................................................... 19 

3.2 Protocol Requirements List (PRL)........................................................................................... 20 

3.2.1 User Needs Column ................................................................................................... 20 

3.2.2 Requirements Column................................................................................................ 20 

3.2.3 Conformance Column ................................................................................................ 20 

3.2.4 Support / Project Requirements Column.................................................................... 21 

3.2.5 Additional Specifications Column............................................................................... 21 

3.2.6 Instructions for Completing the PRL........................................................................... 22 

3.2.7 Conformance Definition.............................................................................................. 22 

3.2.8 Protocol Requirements List (PRL) Table.................................................................... 23 

3.3 Operational Environment Requirements ................................................................................. 30 

3.3.1 Support Live Data....................................................................................................... 30 

3.3.2 Support Batched Data ................................................................................................ 30 

3.4 Data Exchange Requirements ................................................................................................ 30 

3.4.1 Manage the TSS Configuration .................................................................................. 30 

3.4.2 Monitor the Current Status ......................................................................................... 40 

3.4.3 Collection of Sample Data.......................................................................................... 41 

3.5 Multi-Version Interoperability (MVI-Backward Compatibility) .................................................. 42 



Page vi 

3.5.1 Retrieve Most Recent NTCIP 1209:2005 (version v01) 

Conformant Data Sample Table.............................................................................................. 42 

3.5.2 Retrieve NTCIP 1209:2005 (version v01) 

Conformant Historical Sample Data Table.............................................................................. 43 

3.5.3 Loop Output Conditioning Table................................................................................. 43 

SECTION 4 DIALOGS [NORMATIVE]....................................................................................................... 45 

4.1 Tutorial [INFORMATIVE]......................................................................................................... 47 

4.2 Simple Network Management Protocol (SNMP) Interface...................................................... 48 

4.2.1 Generic SNMP Get Interface...................................................................................... 48 

4.2.2 Generic SNMP Get-Next Interface............................................................................. 48 

4.2.3 Generic SNMP Set Interface ...................................................................................... 49 

4.2.4 Variable Binding List Structure ................................................................................... 50 

4.2.5 Additional Requirements ............................................................................................ 50 

4.3 Specified Dialogs..................................................................................................................... 50 

4.3.1 Managing the TSS Configuration ............................................................................... 51 

4.3.2 Monitoring the Status of the TSS ............................................................................... 56 

4.3.3 Retrieving Sample Data from TSS ............................................................................. 57 

4.3.4 Managing the Inductive Loop Features of the TSS.................................................... 61 

4.3.5 Managing the Machine Vision Features of the TSS................................................... 62 

4.4 State Tables ............................................................................................................................ 63 

4.4.1 State Transitions for sensorSystemStatus ................................................................. 63 

SECTION 5 MANAGEMENT INFORMATION BASE (MIB) [NORMATIVE]............................................. 68 

5.1 Transportation Sensor System Objects .................................................................................. 68 

5.2 Sensor Configuration and Capability Objects ......................................................................... 70 

5.2.1 Sensor Reset, Resynchronization, and Diagnostics .................................................. 70 

5.2.2 Sensor System Status................................................................................................ 71 

5.2.3 Sensor System Occupancy Type............................................................................... 72 

5.2.4 Maximum Number of Sensor Zones Parameter......................................................... 72 

5.2.5 Sensor Zone Table..................................................................................................... 72 

5.2.6 Clock Available ........................................................................................................... 79 

5.2.7 Sensor Technology..................................................................................................... 79 

5.2.8 Maximum Sample Data Entries.................................................................................. 79 

5.2.9 Maximum Number of Characters ............................................................................... 80 

5.2.10 Functional Capabilities ............................................................................................... 80 

5.2.11 External Arming Inputs ............................................................................................... 80 

5.2.12 Output Conditioning Table.......................................................................................... 81 

5.2.13 Pending Configuration File Name .............................................................................. 88 

5.3 Sensor Control Objects ........................................................................................................... 89 

5.3.1 Maximum Number of Outputs .................................................................................... 89 

5.3.2 Output Configuration Table ........................................................................................ 89 

5.3.3 Maximum Number of Output Groups ......................................................................... 94 

5.3.4 Output Group Table.................................................................................................... 94 

5.4 TSS Data Collection Objects................................................................................................... 95 

5.4.1 Data Collection Table ................................................................................................. 95 

5.4.2 Data Buffer Table ....................................................................................................... 98 

5.4.3 Zone Sequence Table .............................................................................................. 101 

5.4.4 Sample Data Table................................................................................................... 102 

5.4.5 Zone Class Table ..................................................................................................... 106 

5.5 Inductive Loop Detector Objects ........................................................................................... 106 

5.5.1 Loop System Setup Table ........................................................................................ 106 

5.5.2 Loop Output Conditioning Table............................................................................... 109 

5.5.3 Loop System Status Table ....................................................................................... 112 

5.6 Machine Vision Objects......................................................................................................... 115 

5.6.1 Maximum Camera Count ......................................................................................... 115 




Page vii 

5.6.2 Machine Vision Camera Table ................................................................................. 115 

5.6.3 Image Zone Number................................................................................................. 118 

5.6.4 Image Type............................................................................................................... 118 

5.6.5 Image Overlay Type ................................................................................................. 118 

5.6.6 Image Format ........................................................................................................... 119 

5.6.7 Image Quality ........................................................................................................... 119 

5.6.8 Build Image............................................................................................................... 119 

5.6.9 Build Image Status ................................................................................................... 119 

ANNEX A REQUIREMENTS TRACEABILITY MATRIX (RTM) NORMATIVE ....................................... 121 

ANNEX B OBJECT TREE........................................................................................................................ 150 

ANNEX C TEST PROCEDURES ............................................................................................................. 152 

ANNEX D DOCUMENTATION OF REVISIONS ...................................................................................... 153 

D.1 Systems Engineering Process .............................................................................................. 153 

D.2 General MIB Changes........................................................................................................... 153 

D.3 Deprecated Data Collection Table ........................................................................................ 153 

D.4 Deprecated Data Buffer Table............................................................................................... 153 

D.5 Deprecated Loop Output Conditioning Table........................................................................ 153 

D.6 Added Machine Vision Data Elements.................................................................................. 154 

D.7 Additional Data Elements ...................................................................................................... 154 

FIGURES 

Page 

Figure 1 Typical Physical Architecture........................................................................................................10 

Figure 2 Sample Sequence Diagram for Output Configuration..................................................................47 

Figure 3 SNMP Get Interface......................................................................................................................48 

Figure 4 SNMP GetNext Interface ..............................................................................................................49 

Figure 5 SNMP Set Interface ......................................................................................................................49 

Figure 6 SNMP Interface—View of Participating Classes ..........................................................................50 

Figure 7 Object Tree for NTCIP 1209 v02 ................................................................................................151 

TABLES 

Page 

Table 1 User Needs and National ITS Architecture Flows .........................................................................18 

Table 2 Status Symbols ..............................................................................................................................20 

Table 3 Predicate Notations........................................................................................................................21 

Table 4 Predicate to NTCIP 1209 v02 Section Mapping ............................................................................21 

Table 5 Support / Project Requirement Column Entries.............................................................................21 



Page viii 

< This page intentionally left blank. > 




Page 1 

Section 1 

GENERAL 

1.1 SCOPE 

Communication between an ITS Management Center or portable computer and a Transportation Sensor 

System (TSS) is accomplished by using NTCIP Application Layer services to convey requests to access 

or modify values of TSS data elements resident in the TSS via an NTCIP network. An NTCIP message 

consists of a specific Application Layer service and a set of data elements. An NTCIP message may be 

conveyed using any NTCIP defined class of service that has been specified to be compatible with the 

Simple Transportation Management Framework (STMF). 

The scope of NTCIP 1209 v02 is limited to the functionality related to TSS within a transportation 

environment. NTCIP 1209 v02 defines data elements that are specific to TSS and also defines 

standardized data element groups that can be used for conformance statements. The limits and 

descriptions of the parameters are established to give the user maximum flexibility to operate TSS that 

either existed when NTCIP 1209 v02 was developed or may exist in the future. 

1.2 REFERENCES 

Normative references contain provisions that, through reference in this text, constitute provisions of 

NTCIP 1209 v02. Other references in NTCIP 1209 v02 might provide a complete understanding of the 

entire protocol and the relations between all parts of the protocol. At the time of publication, the editions 

indicated were valid. All standards are subject to revision, and parties to agreements based on this 

standard are encouraged to investigate the possibility of applying the most recent editions of the standard 

listed. 

1.2.1 Normative References 

IAB Std. 16 / RFC 1155 Structure and Identification of Management Information for TCP/IP-based 

Internets 

IAB Std. 16 / RFC 1212 

ISO/IEC 8824-1:2008 

AASHTO / ITE / NEMA 

NTCIP 1103 v02 





Concise MIB Definitions 

Information Technology—Abstract Syntax Notation One (ASN.1): 

Specification of Basic Notation 

Transportation Management Protocols (TMP) 

July 2010 edition published in October 2010 

Global Object (GO) Definitions 

December 2010 edition to be published in 2011 

Simple Transportation Management Framework (STMF) Application 

Profile (AP) (AP-STMF) 

July 2010 edition published in September 2010 

1.2.2 Other References 

IAB Std. 17 / RFC 1213 

Management Information Base for Network Management of TCP/IP-based 

internets:MIB-II 



Page 2 

ISO/IEC 8825-1:2008 





RFC 1157 

David Perkins & Evan 

McGinnis 

Information Technology—ASN.1 Encoding Rules: Specification of Basic 

Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished 

Encoding Rules (DER) 

Structure and Identification of Management Information (SMI) 

published June 2010 

The NTCIP Guide 

published July 2009 

Simple Network Management Protocol (SNMP) 

Understanding SNMP MIBs, New Jersey, Prentice Hall PTR, 1997, ISBN 0- 

13-437708- 

1.2.3 Contact Information 

1.2.3.1 NTCIP Standards 

For revision information on this NTCIP standard, contact: 

NTCIP Coordinator 

National Electrical Manufacturers Association 


Rosslyn, VA 22209-3801 

e-mail: ntcip@nema.org 

For draft revisions to this NTCIP standard, and recommended revisions of the NTCIP Joint Committee, 

visit www.ntcip.org. 

1.2.3.2 Internet Architecture Board (IAB) Documents 

For Internet Architecture Board (IAB) documents, contact: 

Internet Architecture Board (IAB) 

www.rfc-editor.org 

www.rfc-editor.org/repositories.html 

1.2.3.3 ISO/IEC Standards 

Members of ISO maintain registers of currently valid ISO/IEC International Standards. For the U.S., the 

member of ISO is the American National Standards Institute (ANSI), which may be contacted as follows: 

1.3 GENERAL STATEMENTS 

No general statements are included. 

ANSI 

11 West 42nd Street, 13th Floor 

New York, NY 10036 

(212) 642-4900 

http://global.ihs.com 

1.4 TERMS 

For the purposes of NTCIP 1209 v02, the following terms and definitions (with acronyms, where 

appropriate) apply. For terms not defined in this section, English words are used in accordance with their 

definitions in the latest edition of Webster's New Collegiate Dictionary. Electrical and electronic terms not 




Page 3 

defined in this section or in Webster's New Collegiate Dictionary are used in accordance with their 

definitions in IEEE Std 100-2000. 

Arming Enable 

Arming Input Bit 

Arming Pin 

class 

A selected state of an arming input bit or Arming Pin of the TSS that can be 

used to modify its operation. 

An external event that is reported to the TSS using this protocol and used to 

modify its operation. 

A physical input to the TSS that can be monitored and used to modify its 

operation. 

A subdivision of collected historical sample data. 

NOTE—How the sample data is subdivided is manufacturer-specific and is, 

therefore, kept generic in NTCIP 1209 v02. 

ConOps 

CTime 

delay 

deprecated 

Concept of Operations 

CTime is a function that converts a long integer, pointed to by a clock function, 

representing the time in seconds since the Epoch (00:000:00 UTC, January 1, 

1970), and returns a pointer to a 26-character string of the form Www Mmm dd 

hh:mm:ss yyyy \n\0 (e.g., Thu Nov 24 18:22:48 2001\n\0) with Www being 

weekday, Mmm being month, dd being day, hh being hour, mm being minute, ss 

being second, yyyy being year, \n being a new line control code, and \0 being a 

null-character control code. All fields have a consistent width. Time zone and 

daylight saving time (DST) corrections are made before string generation. 

A feature that allows the detection output from a TSS detector to be deferred for 

a user set time period. 

In the context of a MIB, ‘deprecated’ is an object STATUS value that indicates 

the object is valid in limited circumstances and may have been replaced by 

another. 

NOTE—To maintain multi-version interoperability (MVI-backward compatibility) 

for legacy NTCIP implementations, objects with a STATUS value of ‘deprecated’ 

may require support. When necessary to support legacy NTCIP 

implementations, required support for objects with a STATUS value of 

‘deprecated’ is indicated using the Profile Implementation Conformance 

Statement (PICS), Protocol Requirements List (PRL). From NTCIP 8004 v02. 

DST 

extension 

Fail-Safe Mode 

feature 

Firmware Version 

Daylight Saving Time 

A feature that allows the detection output from a TSS detector to be lengthened 

for a user set time period. 

Capable of compensating automatically and safely for a failure, as a mechanism 

or power source. 

A service provided by or behavior of the TSS. 

A manufacturer specified description for identifying the software currently 

embedded in the TSS. 



Page 4 

Hardware Version 

interchangeability 

interoperability 

A manufacturer specified description for identifying the electronic components 

that comprise the TSS. 

A condition that exists when two or more items possess such functional and 

physical characteristics as to be equivalent in performance and durability, and 

are capable of being exchanged one for the other without alteration of the items 

themselves, or adjoining items, except for adjustment, and without selection for 

fit and performance. (National Telecommunications and Information 

Administration, U.S. Department of Commerce) 

The ability of two or more systems or components to exchange information and 

use the information that has been exchanged. 

NOTE—From IEEE Standards Dictionary, Glossary of Terms and Definitions. 

Live Data 

LSB 

Management 

Information Base 

(MIB) 

Management 

Station 

MSB 

MVI 

Near Real-Time 

Data 

normalized 

obsolete 

A specific operational network configuration between the management station 

and the TSS where the information exchange can be performed without the 

need for initiating and terminating a physical network connection between the 

management station and TSS. From a network perspective, this configuration is 

an ‘always on’ connection, where the management station has access to the 

‘current’ information available in the TSS. 

Least Significant Bit 

A structured collection or database of related managed objects defined using 

Abstract Syntax Notation One (ASN.1). 

NOTE—The information is provided in Abstract Syntax Notation 1 (ASN.1) 

format. From NTCIP 8004 v02 and ISO/IEC 8824-1:2008 and ISO/IEC 8825- 

1:2008.” 

A remote computer (e.g., Traffic Management Center), local computer (e.g., 

Laptop), or local controller (e.g., Traffic Controller). 

Most Significant Bit 

Multi-Version Interoperability (backward compatibility) 

Data that depicts an event as it existed at the current time less the processing 

time. The data varies from real time data because it is dependent on the type 

and speed of transmission. This data is useable for identifying changes in traffic 

flows. 

Process of reducing sample data to a common denominator to accommodate 

comparison of the measured data. 

In the context of a MIB, ‘obsolete’ is an object STATUS value that indicates the 

definition is no longer valid, was found to be flawed, redundant, or was not 

useful. 

NOTE—In the next (or some future) edition of the standard, the object or group 

with a STATUS value of ‘obsolete’ may be removed. This definition is modified 

from Understanding SNMP MIBS. From NTCIP 8004 v02. 




Page 5 

occupancy 

output 

Output Mode 

Output Group 

PRL 

protocol 

A measurement of vehicle presence within a zone of detection, expressed in 

seconds of time a given point or area is occupied by a vehicle. 

The condition of an on/off status generated by a change of state. 

There are two common modes, Presence and Pulse. In the presence output 

mode, a detection of a vehicle is output constantly while the vehicle is in the 

zone. In the pulse output mode, a detection is output for 125 milliseconds (± 25 

milliseconds) and then the zone is retuned. 

Represents a multiple of eight (8) sequentially numbered outputs. Output Group 

1 consists of Outputs 1 to 8, Output Group 2 consists of Outputs 9 to 16, etc. 

Protocol Requirements List 

A specific set of rules, procedures, and conventions defining the format and 

timing of data transmissions between devices that are accepted and used to 

understand each other. 

NOTE—From NTCIP 8004 v02. 

Protocol Version 

Requirement 

Requirements 

Traceability 

RTC 

RTM 

Sample Period 

Sensitivity 

Sensitivity Mode 

Sensor 

SEP 

SNMP 

Transportation 

Sensor System 

(TSS) 

User 

A standardized description for identifying the version of the TSS standard to 

which the TSS is designed to conform. 

A condition or capability to which a system must conform, either derived directly 

from the user needs, or stated in a contract, standard, specification, or other 

formally imposed document. A desired feature, property, or behavior of a 

system. 

The ability to follow or study the logical progression among the needs, 

requirements, and design details in a step-by-step fashion. 

Real Time Clock 

Requirements Traceability Matrix 

Duration of time in seconds when data for the zone is being collected. 

The ability of the TSS to react to incoming signals, expressed as the minimum 

input signal required to produce an output signal. 

A characteristic of the loop detector being used. It is defined as either ∆L/L, 

∆L/√L, or ∆L. 

A physical device used for sensing traffic. 

Systems Engineering Process 

Simple Network Management Protocol 

Any system capable of sensing and communicating near real-time traffic 

parameters using NTCIP. 

A person who will utilize the system that is developed. 



Page 6 

User Need 

Virtual Zone 

Zone 

The business or operational problem (opportunity) that must be fulfilled in order 

to justify purchase or use. While this is termed a ‘user need’ within the NTCIP 

community, it reflects needs of all stakeholders. 

A logical combination of one or more zones to create a new zone with its own 

conditioning and Arming Enables. This is useful in combining zones to a single 

zone to provide one output from many zones. This can also be used to alias a 

zone so that the same zone can provide multiple outputs, each with different 

conditioning parameters, sample periods, and/or trigger usage. 

An area in which traffic parameters can be measured and/or traffic data can be 

generated. 

NOTE—A zone may denote or represent a lane of a freeway, a left turn lane, or 

even a multiple lane area. The zone may be either physical or non-intrusive. 

Examples of this are a physical loop cut into the roadway or a spot on a roadway 

where a video image processor is measuring data or detecting presence. In 

NTCIP 1209 v02, a Zone is independent of the underlying technology used to 

measure and collect its data. Further, the term ‘sensor zone’ is used 

interchangeably with the term ‘zone,’ because a predecessor of NTCIP 1209 

v02 used the term ‘sensor zone,’ and using the term ‘zone’ throughout would 

have necessitated changes in OBJECT-TYPE, and possible deprecation. 

Therefore, both terms are used interchangeably. 

Zone Options 

Special settings for controlling the behavior of zones. 




Page 7 

Section 2 

CONCEPT OF OPERATIONS 

[Normative] 

Section 2 defines the user needs that subsequent sections address. Accepted System Engineering 

Process (SEP) details that requirements should only be developed to fulfill well-defined user needs. The 

first stage in this process is to identify the ways in which the system is to be used. For NTCIP 1209 v02, 

this entails identifying the various ways in which transportation operations personnel may use TSS 

information to fulfill their duties. 

This concept of operations (ConOps) provides the reader with: 

a) A detailed description of the scope of NTCIP 1209 v02; 

b) An explanation of how a TSS is expected to fit into the larger context of an ITS system; 

c) A starting point in the procurement process; and 

d) An understanding of how NTCIP 1209 v02 is designed. 

Section 2 is intended for all readers, including: 

a) Transportation operations managers 

b) Transportation operations personnel 

c) Transportation engineers 

d) System integrators 

e) Manufacturers 

For the first three categories of readers, Section 2 provides a useful understanding of how TSS 

equipment can be used in the reader’s system. For this audience, Section 2 serves as the starting point in 

the procurement process, enabling readers to become familiar with each NTCIP 1209 v02 feature and 

determine whether that feature is appropriate for their implementation. If it is, then an agency’s 

procurement specification should require support for that feature and all of the mandatory requirements 

related to that feature. 

For the last two categories of readers, Section 2 is useful to gain a more thorough understanding as to 

why the more detailed requirements (specified in subsequent sections) exist. 

2.1 TUTORIAL 

The size and technical level of detail contained in NTCIP 1209 v02 might be a bit intimidating. Therefore, 

Section 2.1 has been added to provide a more manageable overview. 

A Concept of Operations (ConOps) describes a proposed system from the user's perspective. Typically, a 

ConOps is used on a project to ensure that system developers understand user needs. In NTCIP 

standards, the ConOps documents the intent of each feature for which an NTCIP standard supports a 

communications interface. It also serves as a starting point for users to select which features may be 

appropriate for their project. 

The ConOps starts with a discussion of the current situation and issues that have led to the need to 

deploy systems covered by the scope of an NTCIP standard, and to the development of an NTCIP 

standard itself. This discussion is presented in lay terms so that both potential users of the system and 

system developers can understand and appreciate the situation. 

The ConOps then documents key aspects about the proposed system, including the: 



Page 8 

a) Reference physical architecture—The reference physical architecture defines the overall context of 

the proposed system and defines the specific interface addressed. The reference physical 

architecture may be supplemented with one or more samples that describe how the reference 

physical architecture may be realized in an actual deployment. 

b) Architectural Needs—Architectural needs discuss the issues and needs relative to the system 

architecture that have a direct impact the subject area. 

c) Features—The features identify and describe the various functions that users may want the TSS to 

perform. These features are derived from the high-level user needs identified in the problem 

statement, but are refined and organized into a more manageable structure that forms the basis of 

the Protocol Requirements List (PRL) and Requirements Traceability Matrix (RTM) contained in 

Section 3 and Annex A, respectively. 

The architectural needs and features are collectively called user needs. Section 3 uses these user needs 

in the analysis of the system to define the various functional requirements of a TSS. Each user need is 

required to trace to one or more functional requirements, and each functional requirement is required to 

derive from at least one user need. This traceability is shown in the PRL in Section 1.1.1. 

While NTCIP 1209 v02 is intended to standardize communications across a wide range of deployments, it 

is not intended to mandate support for every feature for every deployment. Therefore, the PRL also 

defines each user need and requirement as mandatory, optional, or conditional. The only items marked 

mandatory are those that relate to the most basic functionality of the TSS. To obtain a TSS that meets 

specific needs, the user first identifies which optional needs are necessary for the specific project. 

Each requirement identified is then presented in the RTM in Annex A, which defines how the requirement 

is fulfilled through the standardized dialogs and data element definitions provided in Section 4 and 

Section 5, respectively. 

2.1.1 Background 

NTCIP 1209 v02 is a standard that specifies the logical interface between Transportation Sensor 

Systems (TSS) and the host systems that control them (commonly referred to as central systems). NTCIP 

1209 v02 describes the supported TSS interface functionality in terms of user needs and requirements. 

As for limitations, NTCIP 1209 v02 defines data that could be transmitted between a central system and a 

conformant TSS, but it does not define the functionalities and functions available within a TSS or a central 

system. Also, NTCIP 1209 v02 does not claim to address all potential capabilities of a TSS or a 

controlling/monitoring central system, because such a claim would not permit progress (i.e., if the 

possibility of defining extensions is precluded, no additional functionalities could be added, either by 

subsequent versions of NTCIP 1209 v02 or by vendors or agencies). 

It is also of utmost importance to understand that not all of the functionalities have to be supported by a 

TSS (or a central system) to claim conformance to NTCIP 1209 v02. Instead, the project-specific agency 

specifications that reference and incorporate desired applicable functionalities from NTCIP 1209 v02 are 

the guiding requirements that determine compliance. See NTCIP 9001 v04 for further information about 

the relationship between conformance to a standard, and compliance with an agency specification. 

2.1.2 Who are You? 

In developing NTCIP 1209 v02, certain assumptions were made about readers and readers’ needs. 

Target readers for NTCIP 1209 v02 include those who: 

a) Have heard about NTCIP and are interested in its applicability for deploying TSS; 

b) Are involved in writing agency specifications to procure TSS; 

c) Are involved in reviewing submittals to procure TSS; 

d) Are involved in software development, be it the firmware of a sensor or the software of the central 

system; 

e) Are involved in testing sensors or central systems; or 




Page 9 

f) Are involved in the operational use of these types of sensors. 

2.1.3 NTCIP 1209 v02 Organization 

NTCIP 1209 v02 contains the following sections: 

a) Section 1—General—This section provides the user with references, terms, and other information. 

b) Section 2—Concept of Operations (ConOps)—This section provides a description of user needs 

(needs for features and needs related to the operational environment) applicable to TSS. 

c) Section 3—Functional Requirements—This section defines the functional requirements that address 

the user needs identified in the ConOps. It includes a Protocol Requirements List (PRL) that defines 

conformance requirements, thereby allowing users to select the desired options for a particular 

project. 

d) Section 4—Dialogs—This section describes how each functional requirement is fulfilled. Dialogs 

define the standardized procedures for a central system to manage a sensor. Interface specifications 

define the operations that are allowed by the sensor and how data elements are interrelated. 

e) Section 5—Management Information Base (MIB)—This section defines the data elements (object 

definitions) exchanged during communications, and includes a Management Information Base (MIB). 

f) Annex A—Requirements Traceability Matrix (RTM)—This annex provides a table that traces each 

requirement to a dialog, one or more interfaces, and its associated list of objects. 

g) Annex B—Object Tree—This annex provides a depiction of the high-level object tree showing the 

nodes and some of the scalar objects. This object tree provides the user with a high-level orientation 

tool to navigate the data elements. 

h) Annex C—Test Procedures—This annex is a placeholder for standardized test procedures that 

address TSS needs and requirements. No test procedures are yet provided; however, when 

developed and accepted, Annex C is designated for test procedures. 

i) Annex D—Documentation of Revisions—This annex documents significant revisions between NTCIP 

1209 v02, and its predecessor NTCIP 1209:2005. 

2.1.4 Sections for Specific Audiences 

NTCIP 1209 v02 has been designed for different audiences. The following guidance identifies the most 

relevant NTCIP 1209 v02 section(s) for a specific audience. For example, Agency Specification Writers / 

Purchasers, may benefit from an understanding of functional and operational requirements and contexts 

for which the overall technical requirements of the TSS are to be used. In contrast, Submittal Reviewers, 

Firmware/Software Developers, and/or Tester, may wish to additionally focus on agency specifications, 

many elements of which may be derived from selected sections of NTCIP 1209 v02. Specific audiences 

are encouraged to focus on the sections indicated: 

a) General Interest—Review Sections 1 and 2. 

b) Specification Writers/Purchasers—Review Sections 1, 2, and 3. 

c) Submittal Reviewers—Review Sections 1, 2, and 3, and Annex A (RTM). 

d) Firmware/Software Developers—Review all Sections and Annexes. 

e) Testers—Review all Sections and Annexes. 

f) Operators—Review Sections 1 and 2. 

2.2 CURRENT SITUATION AND PROBLEM STATEMENT 

Transportation system managers use TSS in a variety of ways to improve transportation system 

operations. To facilitate efficient movement within a transportation system, system operators need timely 

and accurate information on traffic flow within the system. This is typically accomplished by measuring 

traffic parameters at desired locations within the transportation system. 



Page 10 

2.3 REFERENCE PHYSICAL ARCHITECTURE 

NTCIP 1209 v02 addresses the communications interface between a management station and a TSS. 

The following paragraphs further explain the typical physical architectures used in conjunction with TSS 

and addressed by NTCIP 1209 v02. 

2.3.1 Typical Physical Architecture 

Once installed, a management station is able to communicate with the TSS through one or more of the 

following three mechanisms: 

a) Remote Computer—This type of operation configures operational parameters and retrieves 

measured traffic parameters from a computer located at a remote location, such as a Traffic 

Management Center (TMC). This is known as either 'central' or 'remote' operation. 

b) Local Controller—This type of operation configures operational parameters and retrieves measured 

traffic parameters through a local controller such as a traffic controller. 

c) Local Computer—This type of operation performs the same functions as a remote computer, but 

uses a portable (e.g., laptop) computer connected directly to a port on the TSS. This port may be the 

same port used for the other communications mechanisms, or may be a dedicated port for this 

purpose. 

Several management stations may communicate with the same TSS. The user should ensure that only 

one management station at a time configures the operational parameters of the TSS. All management 

stations may retrieve measured traffic parameters. 

The connection between the remote computer and a TSS runs over a telecommunications network, which 

can be either wireline or wireless in nature. 

NTCIP 1209 v02 is only concerned with the interface between an external computer and the TSS. To 

fulfill all of the end-user services, additional requirements may be necessary for the external management 

stations. 

Figure 1 depicts the typical physical architecture of the key components related to TSS. 

Management Stations 

TSS 

Zones 

Remote Computer 

(TMC) 

NTCIP 


TSS (Sensor) 

Zone 

1…X 

Local Controller 

(Traffic / Ramp) 



TSS (Sensor) 

Local Controller 

Zone 

1…X 

Covered by 

NTCIP 1209 v02 


TSS (Sensor) 

Machine Vision 

Zone 

1…X 

Local Computer 

(Laptop) 


Figure 1 Typical Physical Architecture 




Page 11 

2.3.2 Transportation Sensor Systems (TSS) 

The selection of Transportation Sensor System (TSS) as a name for what was originally regarded as 

‘advanced sensors’ stemmed from the realization that modern sensors extend well beyond the simple 

detection of automobiles and now include light-rail vehicles, pedestrians, and many other modes of 

transportation. In addition, modern detection devices are now viewed as sensing systems, rather than 

simple sensors or detectors. As a result, the name Transportation Sensor System (TSS) has evolved to 

identify a class of technology that is used for detection within the transportation community. 

A TSS is defined as any system capable of sensing and communicating near real-time traffic parameters 

using the NTCIP. See Section 1.4. 

In its simplest form, a TSS could be a single loop detector that is capable of communicating using NTCIP. 

Other more elaborate systems can include visual image processing systems that are used for sensing 

and communicating a variety of traffic parameters. The key factor that sets a TSS apart from a simple 

detector is the ability to communicate. Ultimately, one can envision a scenario where a combination, 

including a simple detector and some sort of remote processing unit with communications capabilities, 

could be configured as a TSS (examples include a traffic signal controller, ramp metering controller, etc.) 

However, traffic signal controllers and ramp metering controllers (as examples) might use their own 

detection-related data elements that are designed specifically to address their primary function. 

2.3.2.1 Description of Zone 

A zone is an area within which traffic parameters can be measured. A zone is an abstract representation 

of area that is independent of technology. TSS data elements allow up to 255 zones per TSS. 

Traditionally, the terminology ‘sensor’ and ‘detector’ were used in a variety of ways that often referred to 

the physical device used for detection or the area where the detection was occurring. Sometimes these 

terms meant an inductive loop amplifier or some other device used for measuring traffic parameters, and 

other times these terms defined the area where the traffic measurements were being taken, as is the 

case with some visual image processing systems. The use of the term ‘zone’ as a descriptor for any 

entity capable of sensing or measuring traffic parameters and/or gathering traffic data is an effort to move 

away from technology dependencies and ambiguous terminology. 

2.3.2.2 Description of Virtual Zone 

A virtual zone is the term used in NTCIP 1209 v02 to identify a zone that is created as the result of logical 

combinations of physical zones. For example, in the case of an ‘OR’ combination of three detector zones 

mapped to one output, the three physical zones are logically grouped to a fourth zone that exists only to 

provide the resultant output. This fourth zone might be referred to as a virtual zone since it has no direct 

sensing capability. This virtual zone is the result of the logical combination of other zones and would 

otherwise have all the characteristics associated with a physical zone. There is no differentiation in this 

standard between ‘zone’ and ‘virtual zone’, since all zones have identical characteristics and can be used 

in either fashion. The concept of virtual zones is presented here only as a means of describing the 

ConOps for logically combining zones. 

2.3.3 TSS Technologies 

TSS can be based on many different sensing technologies. Each sensing technology has strengths and 

weaknesses. Not all sensing technologies can measure all traffic parameters. The configuration 

requirements for sensing technologies differ and are addressed on a technology-by-technology basis. 

Although all sensing technologies can operate within the TSS framework, each sensing technology may 

require separate configuration information. Discussions of sensing technologies included in NTCIP 1209 

v02 follow. 



Page 12 

2.3.3.1 Inductive Loop 

Inductive loop vehicle detectors have existed since the 1950s and are the most used technology for 

vehicle detection. Inductive loop detectors sense changes in a magnetic field created by a coil (loop) of 

wire embedded in the driving surface. As electrically conductive material enters the loop, the amount of 

energy that can be stored in the magnetic field (inductance) of the loop is decreased. This decrease in 

inductance is measured by the detector and, when a predetermined amount of change has been sensed, 

a detect signal is output. Current inductive loop detectors are microprocessor-based and implement 

advanced algorithms to provide accurate, dependable, and effective vehicle detection. 

2.3.3.2 Machine Vision (Video) 

Machine vision is a detection technology where video is processed to determine various elements of 

vehicle detection. Analog or digital video cameras are mounted above ground and provide images of 

vehicle traffic to a video processor. Video is processed through the use of various algorithms to determine 

the presence or non-presence of vehicles as well as to calculate various traffic parameters, such as 

counts, speeds, and lane occupancy. 

2.4 ARCHITECTUAL NEEDS 

2.4.1 Fundamental Needs Driving TSS Deployment 

Access to timely and accurate traffic parameters provides the information necessary to facilitate efficient 

movement within a transportation system. 

2.4.2 Operational Environment 

NTCIP 1209 v02 addresses the interface between a TSS and a management station. To enable 

communications between these components, the management station needs to establish a 

communications link with the desired TSS. 

2.4.2.1 Live Data Exchange 

The typical operational environment allows the management station to monitor and control the TSS by 

issuing requests (e.g., requests to access and/or alter configuration parameters or requests to access 

measured traffic parameters). In this environment, the TSS responds to requests from a management 

station immediately (e.g., through the provision of the requested parameters or success/failure notice of 

configuration changes). Information from one TSS can be requested by many management stations (e.g., 

intersection control, ramp metering, traffic management center). 

2.4.2.2 Support Batched Off-Line Data Logs 

Some TSS operational environments do not have always-on connections (e.g., dial-up links). In such 

environments, a transportation system operator may wish to define conditions under which data is placed 

into a log, which can then be uploaded at a later time. 

2.5 FEATURES 

Section 2.5 identifies and describes the various standard features that may be offered by a TSS. Section 

3 uses these features in the analysis of the system to define the various functional requirements of a 

TSS. A conformant TSS may offer additional features, as long as they are conformant with NTCIP 1209 

v02 requirements. 

NOTE—Off-the-shelf interoperability and interchangeability are achieved through well-documented 

features broadly supported by the industry as a whole. Designing a system that uses features not 

standardized or not typically deployed in combination with one another inhibits the goals of 

interoperability and interchangeability, especially if the documentation of these features is not available 

for distribution to system integrators. NTCIP 1209 v02 and other standards allow the use of additional 

features to support innovation, which is constantly needed within the industry, but users should be aware 

of the risks to interoperability when doing so. 




Page 13 

The operation of a TSS can be categorized into four major areas: 

a) Configure the TSS 

b) Control the TSS 

c) Monitor the TSS 

d) Collect data from the TSS 

2.5.1 Configure the TSS 

The various sub-features for managing the TSS configuration include: 

a) Determine the TSS Identity 

b) Determine TSS Capabilities 

c) Determine the Sequence of Sample Periods 

d) Determine the Age of Sample Data 

e) Configure Zones 

f) Configure Outputs 

g) Configure Arming Enables 

h) Configuration Files 

These sub-features are detailed subsequently. 

2.5.1.1 Determine the TSS Identity 

The type of sensor technology determines what specific features may be available. The manufacturer, 

firmware version, and hardware version allow the management station to determine what equipment is in 

the field to facilitate preventive maintenance and upgrades. The TSS version allows the management 

station to properly communicate with the TSS. 

This feature allows the management station to determine basic information about the TSS, such as the 

sensor technology, manufacturer, model, firmware version, hardware version, TSS protocol version, and 

TSS standards revision. 

2.5.1.2 Determine TSS Capabilities 

The capabilities of the TSS are needed to determine how to configure and manage the TSS. 

This feature allows the management station to determine the capabilities of the TSS, such as the 

maximum number of zones, maximum number of historical data entries per zone, maximum number of 

sample periods per zone, maximum number of outputs, maximum number of output groups, type of 

occupancy used, maximum number of classes (subdivisions of collected data), maximum number of 

characters for labels, availability of a Real Time Clock (RTC), and whether the RTC supports DST. 

2.5.1.2.1 Determine TSS Support for Sampling 

This feature allows the management station to determine if the TSS supports sampling. Support for the 

sampling feature indicates that the TSS is capable of collecting sample data and storing it for retrieval. 

2.5.1.2.2 Determine TSS Support for Timing 

This feature allows the management station to determine if the TSS supports timing functions. Support for 

the timing feature indicates that the TSS is capable of modifying the operation of zones and outputs 

through user-specified timing parameters. 

2.5.1.2.3 Determine TSS Support for Speed 

This feature allows the management station to determine if the TSS supports speed functions. Support 

for the speed feature indicates that the TSS is capable of providing (measuring or estimating) vehicle 

speed and storing it for retrieval through the sampling functions. 



Page 14 

2.5.1.2.4 Determine TSS Support for Real Time Clock (RTC) 

This feature allows the management station to determine if the TSS supports an RTC. Support for the 

RTC feature indicates that the TSS is capable of providing actual local time. 

2.5.1.3 Determine the Sequence of Sample Periods 

This feature allows the management station to determine the sequence of sample periods so that 

aggregate data can be used to identify changes in traffic. 

2.5.1.4 Determine the Age of Sample Data 

This feature allows the management station to determine the age of sample period data so that the 

relevance of the data to current traffic conditions can be determined. 

2.5.1.5 Configure Zones 

This feature allows the management station to configure the sampling period, a sensing zone (e.g., 

identifying label, number of classes, combination of multiple zones into a single zone, sequencing of 

zones), and other zone options (e.g., enabled or disabled, fault detection thresholds). Also, this feature 

allows the management station to configure the paired zone settings (e.g., leading placement, trailing 

placement, method of estimating speed if one zone of the pair fails) that may be used in speed 

calculations within the TSS. 

This feature also allows for specific technologies of TSSs to have additional operational parameters. For 

inductive loops, this would include additional parameters such as sensitivity mode, sensitivity, and 

frequency setting. 

2.5.1.6 Configure Arming Enables 

This feature allows the management station to configure the Arming Enables that are used to modify an 

output and its delay and extension timing (e.g., Arming Pins, Arming Input Bits). 

NOTE—Previously, some detection devices provided inputs that could be used to modify the operation of 

the detection device. These modifications usually dealt with delay and extension timing and were referred 

to in many ways (phase green inputs, delay inhibits, green inputs, etc.). A typical use of these inputs 

would be a right turn only lane that allows right turn on red at a signalized intersection. The input would 

be controlled by the green for the phase that would be active when the right turn lane would have a green 

display. The detection device for the right turn lane would then be programmed to have some amount of 

delay. This would keep the traffic controller from receiving a detection from vehicles that arrived and then 

turned right on red unless a vehicle stayed in the right turn lane for at least the delay time. When the 

phase for the right turn is green, the delay needs to be turned off so that the phase can extend correctly. 

Arming Enables are a logical enhancement to these inputs to allow greater flexibility in the control and the 

use of these inputs. Arming Enables are made up of Arming Pins and Arming Input Bits. Arming Pins are 

the physical inputs into the TSS, and Arming Input Bits are external status that are reported to the TSS 

using this protocol. For features that use Arming Enables, the ON or the OFF state of each Arming 

Enable can be used to activate a feature. Arming Enables that do not have an ON or OFF state set as an 

enable are ignored. If the Arming Pin inputs are dc, then a low input is an ON and a high input is an OFF. 

If the Arming Pin inputs are ac, then a low input is an OFF and a high input is an ON. 

2.5.1.7 Configure Outputs 

This feature allows the management station to configure the outputs to report the state of zones. (e.g., 

assigning an output to a zone, conditioning of outputs to include delay and extension, assigning fail-safe / 

fail-secure mode of operation, force output on/off). 

NOTE—The fail-safe or fail-secure modes of operation determine how a TSS outputs for a zone when it 

fails. In the fail-safe mode, the TSS outputs a constant detect during a zone failure. In the fail-secure 

mode, the TSS outputs a no detect during a zone failure. 




Page 15 

2.5.1.8 Manage Pending Configuration File Name 

This feature allows the management station to transfer, validate, and execute a configuration file. 

2.5.2 Control the TSS 

The various sub-features for controlling the TSS include: 

a) Reset the TSS 

b) Initiate Sensor Diagnostics 

c) Synchronize the TSS 

d) Update Arming Input Bits of the TSS 

e) Manage the Camera 

f) Manage the RTC 

2.5.2.1 Reset the TSS 

This feature allows the management station to set the TSS to a known condition such as restart, 

reinitialize the user settings, or retune. This feature also allows a management station to cause the TSS 

to execute, abort, or validate a pending configuration file. 

2.5.2.2 Initiate Sensor Diagnostics 

This feature allows the operator to initiate sensor diagnostic routines. 

2.5.2.3 Synchronize the TSS 

This feature allows the TSS to set the baseline reference for the sampling period. 

2.5.2.4 Update Arming Input Bits of the TSS 

This feature allows a management station to update the status of the Arming Input Bits of the TSS. 

Arming input bits are updated so that the TSS can monitor external events without the need to physically 

connect an input of the TSS to a point that would allow it to monitor the desired event. This is especially 

desirable if the event to be monitored is not controlled at the same physical location as the TSS (e.g., the 

Red, Yellow, and Green states of a traffic signal, lane control signals, and preemption). 

2.5.2.5 Manage the Camera 

This feature allows a management station to enable or disable detection for a particular camera location. 

This feature would allow a camera that is normally used for detection to be disabled and then panned or 

zoomed to a new location for other uses such as surveillance. This feature also helps a management 

station verify that a camera is working and is pointing at the correct detection area. A management 

station can retrieve the original image used to set up the detection and compare it to a current image to 

verify a camera is properly aimed and has not moved. The image can be retrieved untouched to help 

diagnose camera issues or with the zone or zones overlaid to help verify camera aiming. The image may 

be available in different formats ranging from highest quality for images to be sent to the manufacturer for 

analysis to highly compressed to reduce bandwidth on the network and storage requirements to archive 

the image. To aid the management station, the TSS can associate a name with each of its cameras. This 

feature also allows the management station to determine the number of cameras and their video formats. 

This feature also allows a management station to command the camera to build an image file that can be 

transferred to a management station via FTP. 

2.5.2.6 Manage the Real Time Clock (RTC) 

This feature allows a management station to configure an RTC for the purpose of providing a timestamp 

for sample data. The clock should be able to support Daylight Saving Time (DST) adjustments. 



Page 16 

2.5.3 Monitor Current TSS Status 

The various sub-features for monitoring the current status of the TSS include: 

a) System Status 

b) Sensor Status 

c) Output States 

d) Zone Status 

2.5.3.1 Monitor System Status 

This feature allows the management station to monitor the system status of the TSS such that the 

management station identifies that the system is operating normally (the TSS has not identified a 

hardware or configuration error) or initializing. 

2.5.3.2 Monitor TSS Sensor Status 

This feature allows the management station to monitor the status of each sensor within the TSS. In 

NTCIP 1209 v02, only the sensor status of inductive loop and machine vision sensors are defined. 

For inductive loops, this feature allows the operator to monitor inductance, frequency, inductance change, 

fault history, and fault count. 

For machine vision, this feature allows the operator to monitor video format, image reception diagnostics, 

and contrast loss, along with retrieving a snapshot to verify camera field of view (checking for camera 

movement/alignment issues). 

2.5.3.3 Monitor Output States 

This feature allows the management station to retrieve the states of multiple outputs of the TSS. The 

outputs need to be read often without overloading the communications link, and retrieving multiple 

outputs in the same action helps reduce the communications load. 

2.5.3.4 Monitor Zone Status 

This feature allows the management station to monitor the status of each zone. 

2.5.4 Collect Data from TSS 

The various sub-features for collecting data from the TSS include: 

a) Retrieve In-Progress Sample Data 

b) Retrieve Most Recently Completed Sample Data 

c) Retrieve Historical Sample Data 

2.5.4.1 Retrieve In-Progress Sample Data 

This feature allows the management station to obtain the data from the in-progress (started but not yet 

completed) sample period for use in identifying changes in traffic flow. This data includes the length of 

elapsed time in the reported sample period, volume, percent of occupancy, speed, and zone status 

during the sampling period. 

NOTE—As a TSS may support the Boolean AND and OR operations to combine existing zones into a 

new virtual zone, the sample data reported by a virtual zone has limitations. If any AND logic is used, 

volume is the number of times that the output for the zone was activated. If just OR logic is used, volume 

is the additive total of the volumes of all of the zones that make up the virtual zone. Occupancy is the 

percent of time that the output for the zone was activated. Speed is reported as 65535 as it is not 

straightforward to calculate speed from logically combined zones. Zone Status only shows ‘OK’ if the 

status of all of the logically combined zones was ‘OK’ for the entire sample period. If any zone has a 

status other than ‘OK’ during the sample period, the last status other than ‘OK’ that is identified is the 




Page 17 

status reported. 

2.5.4.2 Retrieve Current Sample Data 

This feature allows the management station to obtain the data from the current sample period for use in 

identifying changes in traffic flow. This data includes when the sample period ended, volume, percent of 

occupancy, speed, and zone status during the sampling period. 

2.5.4.3 Retrieve Historical Sample Data 

This feature allows the management station to retrieve historical sample data from previous sample 

periods for use in identifying changes in traffic flow. This is necessary to deal with communications 

failures and management station startup. 

2.5.5 Multi-Version Interoperability (MVI-Backward Compatibility) 

With the development and publication of newer versions of various NTCIP standards, the need to 

address and ensure multi-version interoperability (MVI-often referred to as ‘backward compatibility’ with a 

previous version, or interoperability to a defined extent with future versions) arises. Section 2.5.5 

provisions are designed to allow MVI. 

NTCIP 1209 v02 is newer than its predecessor, NTCIP 1209:2005. In NTCIP 1209 v02, some objects 

have been deprecated since NTCIP 1209:2005. It is important that these objects still be supported to 

provide interoperability with existing legacy systems. If the implementation does not require 

interoperability with existing legacy systems, then support for the deprecated objects is optional. 

NOTE—NTCIP 1209:2005 is the predecessor of NTCIP 1209 v02. Since NTCIP 1209:2005 did not 

include a major+minor version number as part of the document designation, NTCIP 1209:2005 is referred 

to as NTCIP 1209:2005 (version v01) or NTCIP 1209:2005 v01. 

2.5.5.1 NTCIP 1209:2005 (version v01) Conformant 

This feature allows the management station to support objects in conformance with 

NTCIP 1209:2005 v01. 

2.5.5.1.1 Retrieve NTCIP 1209:2005 (version v01) Conformant Most Recent Sample Data 

This feature allows the management station to retrieve the most recent sample data from a TSS that is 

compliant with NTCIP 1209:2005 v01. 

2.5.5.1.2 Retrieve NTCIP 1209:2005 (version v01) Conformant Historical Sample Data 

This feature allows the management station to retrieve historical sample data from previous sample 

periods from NTCIP 1209:2005 v01 TSS for use in identifying changes in traffic flow. 

2.5.5.1.3 Loop Output Conditioning 

This feature allows a management station to configure for NTCIP 1209:2005 v01 conformance. 

2.6 SECURITY 

NTCIP 1209 v02 does not address any security issues. Any security pertaining to protecting the 

communications with a TSS should be implemented either physically by protecting the communications 

access points, or logically by enabling security features associated with the underlying communications 

protocols. 

2.7 OPERATIONAL POLICIES AND CONSTRAINTS/ASSUMPTIONS 

Operational policies are agency-specific and need to be determined and implemented by the agency 

operating the TSS. NTCIP 1209 v02 does not cover this topic, but instead provides a set of common 

functions that can support an agency's operational policies. 



Page 18 

If assumptions pertaining to the operations of a TSS have been made, they have been stated clearly at 

the locations where they apply. 

2.8 RELATIONSHIP TO THE NATIONAL ITS ARCHITECTURE FLOWS 

There are three National ITS Architecture Flows associated with the operation of a TSS. These are: 

a) Traffic Flow 

b) Traffic Sensor Control 

c) Roadway Equipment Coordination 

Each Architecture Flow is associated with one or more interfaces identified within the National ITS 

Architecture as: 

a) Between the TSS (Roadway Subsystem (RS)) and the Traffic Management Subsystem (TMS) 

b) Between the TSS (Roadway Subsystem (RS)) and Other Roadway Subsystem (ORS) 

The main user need groups (features), as identified previously, are related to the National ITS 

Architecture Flows as indicated in Table 1. 

Table 1 User Needs and National ITS Architecture Flows 

User Need Group Source Architecture Flow Destination 

Configure the Sensor TMS Traffic Sensor Control RS 

ORS Roadway Equipment Coordination RS 

RS Roadway Equipment Coordination ORS 

Monitor the Sensor TMS Traffic Sensor Control RS 

RS Traffic Flow TMS 

ORS Roadway Equipment Coordination ORS 

RS Roadway Equipment Coordination RS 

Retrieve Data RS Traffic Flow TMS 

ORS Roadway Equipment Coordination RS 

RS Roadway Equipment Coordination ORS 




Page 19 

Section 3 

FUNCTIONAL REQUIREMENTS 

[Normative] 

Section 3 defines the Functional Requirements based on the user needs identified in Section 2. Section 3 

includes: 

a) A tutorial 

b) The Protocol Requirements List (PRL)—A Functional Requirement is a requirement of a given 

function and therefore is only required to be implemented if the associated functionality (e.g., user 

need) is selected through the use of the PRL. The PRL also indicates which of the items are 

mandatory, conditional, or optional. The PRL can be used to specify the desired features of a TSS or 

can be used to document the features supported by a manufacturer’s implementation. 

c) Operational Environment Requirements—These requirements relate to the Operational Environment 

user needs defined in Section 2.4.2. 

d) Data Exchange Requirements—These are requirements related to the features identified in Section 

2.5 that can be realized through a data exchange. For example, this includes the requirement to be 

able to determine the output states of the TSS. 

Section 3 is intended for all readers, including: 

a) Transportation operations managers 

b) Transportation operations personnel 

c) Transportation engineers 

d) System integrators 

e) Manufacturers 

Section 3 is useful to the first three categories of readers useful to understand the details of TSS 

requirements. Section 3.2.8 is particularly useful in preparing agency specifications, and the PRL enables 

mapping from its rows to more detailed text in other sections. 

For the last two categories of readers, Section 3 is useful to fully understand what is required of 

equipment conformant with NTCIP 1209 v02 as an interface. Section 3.2.8 may also be used to 

document the capabilities of particular TSS implementation. 

3.1 TUTORIAL [INFORMATIVE] 

Section 3 defines the requirements that are intended to fulfill the user needs identified in Section 2. This 

is achieved through a PRL that traces each user need to one or more requirements. The details of each 

requirement are then presented following the PRL. Functional requirements are presented in three broad 

categories as follows: 

a) Architectural Requirements—These requirements define the required behavior of the system in 

exchanging data across the communications interface, including any restrictions to general 

architectural requirements, based on the architectural needs identified in Section 2. 

b) Data Exchange Requirements—These requirements define the required behavior of the system in 

exchanging data across the communications interface based upon the features identified in Section 

2. 

c) Supplemental Requirements—These requirements define additional requirements of the system that 

are derived from the architectural and/or data exchange requirements but are not themselves 

architectural or data exchange requirements. A given supplemental requirement may relate to 

multiple architectural and/or data exchange requirements. Supplemental requirements frequently 

include range capabilities of the equipment (e.g., how many sample periods is a TSS required to 



Page 20 

support). 

3.2 PROTOCOL REQUIREMENTS LIST (PRL) 

The PRL, provided in the table in Section 3.2.8, maps the user needs defined in Section 2 to the 

requirements defined in Section 3. The PRL can be used to: 

a) Indicate which requirements are to be implemented in a project-specific implementation. 

b) (As a checklist) to reduce the risk of failure to conform to NTCIP 1209 v02 through oversight. 

c) Provide a detailed indication of the capabilities of the implementation. 

d) (As a basis) to initially check the potential interoperability with another implementation. 

3.2.1 User Needs Column 

The PRL is based on the user needs defined in Section 2. The section number and user need name are 

indicated in this column. 

3.2.2 Requirements Column 

The PRL provides traceability by identifying the requirements defined in Section 3 that are associated 

with the user needs. The section number and functional requirement name are indicated in this column. 

3.2.3 Conformance Column 

The following notations and symbols are used to indicate status and conditional status in the PRL in all 

NTCIP standards. Not all of these notations and symbols may be used NTCIP 1209 v02. 

3.2.3.1 Status Symbols 

The symbols in Table 2 are used to indicate status. 

Symbol 

M 

M.# 

O 

O.# 

C 

N/A 

X 

Table 2 Status Symbols 

Status 

Mandatory 

Support of every item of the group labeled by the 

same numeral # required, but only one is active at 

a time 

Optional 

Part of an option group. Support of the number of 

items indicated by the '(range)' is required from all 

options labeled with the same numeral # 

Conditional 

Not applicable (i.e., logically impossible in the 

scope of the standard) 

Excluded or prohibited 

The O.# (range) notation is used to show a set of selectable options (e.g., O.2(1..*) would indicate that 

one or more of the option group 2 options shall be implemented). Two character combinations are used 

for dynamic requirements. In this case, the first character refers to the static (implementation) status, and 

the second refers to the dynamic (use); thus, ‘MO’ means ‘mandatory to be implemented, optional to be 

used.’ 

3.2.3.2 Conditional Status Notation 

The predicate notations in Table 3 may be used. 




Page 21 

Predicate 

: 

:: 

(predicate) 

Table 3 Predicate Notations 

Notation 

This notation introduces a single item that is conditional on the 

. 

This notation introduces a table or a group of tables, all of which are 

conditional on the . 

This notation introduces the first occurrence of the predicate. The 

feature associated with this notation is the base feature for all 

options that have this predicate in their conformance column. 

The : notation means that the status following it applies only when the PRL states that the 

feature or features identified by the predicate are supported. In the simplest case, is the 

identifying tag of a single PRL item. The :: notation may precede a table or group of tables in 

a section or subsection. When the group predicate is true, then the associated section shall be included. 

The symbol also may be a Boolean expression composed of several indices. ‘AND’, ‘OR’, 

and ‘NOT’ shall be used to indicate the Boolean logical operations. 

Table 4 maps the predicates used in NTCIP 1209 v02 to its sections. 

Table 4 Predicate to NTCIP 1209 v02 Section Mapping 

Predicate 

Section 

Loop (Inductive Loop) Indicates that the PRL item applies to Inductive Loops as 

identified by Section 2.5.1.1 

Video (Machine Vision) Indicates that the PRL item applies to Machine Vision as 

identified by Section 2.5.1.1 

RTC (Real Time Clock) Indicates that the PRL item applies to RTCs as identified by 

Section 2.5.1.2.4 

Speed 

Indicates that the PRL item applies to Speed as identified by 

Section 2.5.1.2.3 

Timing 

Indicates that the PRL item applies to Timing as identified by 

Section 2.5.1.2.2 

Sample 

Indicates that the PRL item applies to Sampling as identified by 

Section 2.5.1.2.1 

Version01 or Version1 Indicates that the PRL item applies to objects required to 

maintain MVI with NTCIP 1209:2005 v01 as identified by 

Section 2.5.5.1 

3.2.4 Support / Project Requirements Column 

The support column can be used in an agency specification to identify the required features for a specific 

implementation or by an implementer to identify which features have been implemented. In either case, 

the user circles the appropriate answer (Yes, No, or N/A) in the support column. See Table 5. 

Table 5 Support / Project Requirement Column Entries 

Entry 

Identifier 

Yes 

Supported by the implementation 

No 

Not supported by the implementation 

N/A 

Not applicable 

3.2.5 Additional Specifications Column 

The ‘Additional Specifications’ column may be used in an agency specification to provide additional notes 

and requirements for the specified implementation, or may be used by an implementer to provide any 

additional details about the implementation. In some cases, default text may already exist in this column, 



Page 22 

which the user should complete to fully specify the equipment. However, additional text can be added to 

this field as needed to fully specify a feature. 

3.2.6 Instructions for Completing the PRL 

In the 'Project Requirements' column, each response shall be either selected from the indicated set of 

responses (e.g., Yes / No / N/A), or entered as indicated. 

If a conditional requirement is inapplicable, use the Not Applicable (N/A) choice. If a mandatory 

requirement is not satisfied, exception information shall be supplied by entering a reference Xi, where i is 

a unique identifier, to an accompanying rationale for the non-conformance. When the status is expressed 

as a two-character combination (as defined in Section 3.2.3.1), the response shall address each element 

of the requirement; e.g., for the requirement ‘mo’, the possible compliant responses are ‘yy’ or ‘yn.’ 

3.2.7 Conformance Definition 

To claim ‘Conformance’ to NTCIP 1209 v02, the TSS shall minimally satisfy the mandatory requirements 

as identified in the PRL table. In addition, a conformant TSS may offer additional (optional) features, as 

long as they are conformant with the requirements of this standard and the standards it references. 

NOTE—‘Conformance’ to NTCIP 1209 v02 should not be confused with ‘compliance’ to an agency 

specification. NTCIP 1209 v02 is as broad as possible to allow a very simple TSS to be ‘conformant’ to 

NTCIP 1209 v02. An agency specification needs to identify the requirements of a particular project and 

needs to require support for those requirements. An agency specification should match the requirements 

of a project with the corresponding requirements defined in NTCIP 1209 v02 to achieve interoperability. 

This means that functions and requirements defined as ‘optional’ in NTCIP 1209 v02 might need to be 

selected in an agency specification (in effect made ‘mandatory’). 

A conformant TSS may offer additional features, as long as they are conformant with the requirements of 

NTCIP 1209 v02 and requirements contained in other standards that NTCIP 1209 v02 references (i.e., 

NTCIP 2301 v02, and NTCIP 8004 v01). For example, a TSS may support data that has not been defined 

by NTCIP 1209 v02; however, when exchanged via one of the NTCIP 2301 v02 protocols, the data shall 

be properly registered with a valid OBJECT IDENTIFIER under the Global ISO Naming Tree. 

NOTE—Off-the-shelf interoperability and interchangeability can only be obtained through welldocumented 

features broadly supported by the industry as a whole. Designing a system that uses 

features not defined in a standard or not typically deployed in combination with one another inhibits the 

goals of interoperability and interchangeability, especially if the documentation of these features is not 

available for distribution to system integrators. Standards allow the use of additional features to support 

innovation, which is consistently needed in the industry, but users should be aware of the risks involved 

with using such features. 




Page 23 

3.2.8 Protocol Requirements List (PRL) Table 

User Need 

Section Number 

User Need 

FR Section 

Number 

Functional Requirement 

Conformance 

Support / Project 

Requirement 

2.4 Architectural Needs 

2.4.1 Fundamental Needs Driving TSS Deployment 

2.4.2 Operational Environment 

2.4.2.1 Live Data Exchange 

3.3.1.1 Retrieve Data M Yes 

3.3.1.2 Deliver Data M Yes 

3.3.1.3 Data Retrieval and Data M Yes 

Delivery Action Performance 

2.4.2.2 Support Batched Off-Line Data Logs 

3.3.2.1 Retrieve Historical Sample Data Sample:M Yes/ N/A 

2.5 Features 

2.5.1 Configure the TSS 

2.5.1.1 Determine the TSS Identity 

3.4.1.1.1 

(Loop) 

(Video) 

Additional Specifications 

Determine Sensor Technology M Yes If the sensor technology 

indicates that it is Inductive 

Loop, then the predicate ‘Loop’ 

is true and conformance should 

include those requirements 

indicated by the Loop predicate. 

If the sensor technology 

indicates Machine Vision, then 

the predicate ‘Video’ is true and 

conformance should include 

those requirements indicated by 

the Video predicate. 

3.4.1.1.2 Determine Manufacturer M Yes 

3.4.1.1.3 Determine Model M Yes 

3.4.1.1.4 Determine Firmware Version M Yes 

3.4.1.1.5 Determine Hardware Version M Yes 

3.4.1.1.6 Determine Protocol Version M Yes 

3.4.1.1.7 Determine Standards Revision 

Version 


3.4.1.2.1 Determine Maximum Number of 

Sensor Zones 

3.4.1.2.2 Determine Maximum Number of 

Historical Data Entries per 

Sensor Zone 

3.4.1.2.3 Determine Maximum Number of M 

Outputs 

3.4.1.2.4 Determine Maximum Number of M 

Output Groups 

3.4.1.2.5 Determine Type of Occupancy M 

Used 

3.4.1.2.6 Determine Availability of a Real M 

Time Clock (RTC) 

3.4.1.2.7 Determine if Real Time Clock M 

(RTC) Supports Daylight Saving 

Time (DST) 

M 

M 

Yes 

Yes 

Sample:M Yes/ N/A 

Yes 

Yes 

Yes 

Yes 

Yes 

© 2010 AASHTO / ITE / NEMA Copy Per PRL Distribution Permission


Page 24 

User Need 


2.5.1.2.1 

(Sample) 

2.5.1.2.2 

(Timing) 

2.5.1.2.3 

(Speed) 

2.5.1.2.4 

(RTC) 

User Need 

FR Section 

Number 


Conformance 


Requirement 

3.4.1.2.8 Determine Maximum Number of Sample:M Yes/ N/A 

Classes 

3.4.1.2.9 Determine Maximum Number of M Yes 

Characters for Labels 

3.4.1.2.10 Determine Optional Features M Yes 

Determine TSS Support for Sampling 


3.4.1.2.10 Determine Optional Features M Yes If the features indicate that 

support for Sampling is required, 

then the predicate ‘Sample’ is 

true and conformance should 


indicated by the Sample 

predicate. 

Determine TSS Support for Timing 


support for Timing is required, 

then the predicate ‘Timing’ is 



indicated by the Timing 

predicate. 

Determine TSS Support for Speed 


support for Speed is required, 

then the predicate ‘Speed’ is 



indicated by the Speed 

predicate. 

2.5.1.2.4 Determine TSS Support for Real Time Clock 

(RTC) 

3.4.1.2.6 Determine Availability of a Real 

Time Clock (RTC) 

2.5.1.3 Determine the Sequence of Sample Periods 

3.4.3.1.6 Get Historical Sequence 

Number 

M Yes If the features indicate that 

support for Real Time Clock 

(RTC) is required, then the 

predicate ‘RTC’ is true and 



the RTC predicate. 


2.5.1.4 Determine the Age of Sample Data 

3.4.3.1.1 Get Historical Sample End Time Sample:M Yes/ N/A 

2.5.1.5 Configure Zones 

3.4.1.5.1 Get Zone Options M Yes 

3.4.1.5.2 Get Zone Options Status M Yes 

3.4.1.5.3 Get Zone Sample Period Sample:M Yes/ N/A 

3.4.1.5.4 Get Zone Label O Yes/No 

3.4.1.5.5 Get Zone Boolean AND Zones O Yes/No 

3.4.1.5.6 Get Zone Boolean OR Zones O Yes/No 

Copy Per PRL Distribution Permission 



Page 25 

User Need 


User Need 

FR Section 

Number 


Conformance 


Requirement 

3.4.1.5.7 Set Zone Options M Yes 

3.4.1.5.8 Set Zone Sample Period Sample:M Yes/ N/A 

3.4.1.5.9 Set Zone Label O Yes/No 

3.4.1.5.10 Set Zone Boolean AND Zones O Yes/No 

3.4.1.5.11 Set Zone Boolean OR Zones O Yes/No 

3.4.1.5.12 Get Paired Zone Speed:M Yes/ N/A 

3.4.1.5.13 Get Paired Zone Options Speed:M Yes/ N/A 

3.4.1.5.14 Get Paired Zone Spacing Speed:M Yes/ N/A 

3.4.1.5.15 Get Speed Correction Factor Speed:M Yes/ N/A 

3.4.1.5.16 Set Paired Zone Speed:M Yes/ N/A 

3.4.1.5.17 Set Paired Zone Options Speed:M Yes/ N/A 

3.4.1.5.18 Set Paired Zone Spacing Speed:M Yes/ N/A 

3.4.1.5.19 Set Speed Correction Factor Speed:M Yes/ N/A 

3.4.1.5.20 Get Sensor Zone Average Speed:M Yes/ N/A 

Vehicle Length 

3.4.1.5.21 Get Sensor Zone Length Speed:M Yes/ N/A 

3.4.1.5.22 Set Sensor Zone Average Speed:M Yes/ N/A 

Vehicle Length 

3.4.1.5.23 Set Sensor Zone Length Speed:M Yes/ N/A 

3.4.1.5.24 Get Sensor Zone Loop Layout Loop:M Yes/ N/A 

3.4.1.5.25 Set Sensor Zone Loop Layout Loop:M Yes/ N/A 

3.4.1.5.26 Set Zone Sensitivity Mode Loop:M Yes/ N/A 

3.4.1.5.27 Set Zone Sensitivity Loop:M Yes/ N/A 

3.4.1.5.28 Set Sensor Zone Frequency Loop:M Yes/ N/A 

Range 

3.4.1.5.29 Get Zone Sensitivity Mode Loop:M Yes/ N/A 

3.4.1.5.30 Get Zone Sensitivity Loop:M Yes/ N/A 

3.4.1.5.31 Get Sensor Zone Frequency Loop:M Yes/ N/A 

Range 

3.4.1.5.32 Get Zone Output Mode M Yes 

3.4.1.5.33 Get Output Max Presence Time Timing:M Yes/ N/A 

3.4.1.5.34 Get Output Delay Time Timing:M Yes/ N/A 

3.4.1.5.35 Get Output Extension Time Timing:M Yes/ N/A 

3.4.1.5.36 Set Zone Output Mode M Yes 

3.4.1.5.37 Set Output Max Presence Time Timing:M Yes/ N/A 

3.4.1.5.38 Set Output Delay Time Timing:M Yes/ N/A 

3.4.1.5.39 Set Output Delay Enables Timing:O.3 Yes/No/ N/A 

3.4.1.5.40 Set Output Extension Time Timing:M Yes/ N/A 

3.4.1.5.41 Set Output Extension Enables Timing:O.3 Yes/No/ N/A 

3.4.1.5.42 Get Output Delay Mode Timing:O.3 Yes/No/ N/A 

3.4.1.5.43 Set Output Delay Mode Timing:O.3 Yes/No/ N/A 

3.4.1.5.44 Get Output Extension Mode Timing:O.3 Yes/No/ N/A 

3.4.1.5.45 Set Output Extension Mode Timing:O.3 Yes/No/ N/A 

3.4.1.5.46 Get Zone Output Sequenced Timing:O Yes/No/ N/A 

3.4.1.5.47 Set Zone Output Sequenced Timing:O Yes/No/ N/A 

3.4.1.5.48 Get Output Delay Enables Timing:O.3 Yes/No/ N/A 

3.4.1.5.49 Get Output Extension Enables Timing:O.3 Yes/No/ N/A 

3.4.1.5.50 Get No Activity Fault Time M Yes 

3.4.1.5.51 Get Max Presence Fault Time M Yes 

3.4.1.5.52 Get Erratic Counts Fault Time M Yes 

3.4.1.5.53 Get Erratic Counts Threshold M Yes 

3.4.1.5.54 Set No Activity Fault Time M Yes 




Page 26 

User Need 


User Need 

FR Section 

Number 


Conformance 


Requirement 

3.4.1.5.55 Set Max Presence Fault Time M Yes 

3.4.1.5.56 Set Erratic Counts Fault Time M Yes 

3.4.1.5.57 Set Erratic Counts Threshold M Yes 

2.5.1.6 Configure Arming Enables 

3.4.1.3.11 Get External Arming Inputs Timing:O.3 Yes/No/ N/A 

3.4.1.3.12 Set External Arming Inputs Timing:O.3 Yes/No/ N/A 

3.4.1.5.39 Set Output Delay Enables Timing:O.3 Yes/No/ N/A 

3.4.1.5.41 Set Output Extension Enables Timing:O.3 Yes/No/ N/A 

3.4.1.5.48 Get Output Delay Enables Timing:O.3 Yes/No/ N/A 

3.4.1.5.49 Get Output Extension Enables Timing:O.3 Yes/No/ N/A 

3.4.1.6.9 Get Output Arming Mode Timing:O.3 Yes/No/ N/A 

3.4.1.6.11 Set Output Arming Mode Timing:O.3 Yes/No/ N/A 

2.5.1.7 Configure Outputs 

3.4.1.6.1 Get Ouput Sensor Zone M Yes 

3.4.1.6.2 Get Output Failsafe Mode M Yes 

3.4.1.6.3 Get Output Mode Status M Yes 

3.4.1.6.4 Get Output Label O Yes/No 

3.4.1.6.5 Set Output Sensor Zone M Yes 

3.4.1.6.6 Set Output Failsafe Mode M Yes 

3.4.1.6.7 Set Output Label M Yes 

3.4.1.6.8 Get Output Arming Enables Timing:O.3 Yes/No/ N/A 

3.4.1.6.9 Get Output Arming Mode Timing:O.3 Yes/No/ N/A 

3.4.1.6.10 Set Output Arming Enables Timing:O.3 Yes/No/ N/A 

3.4.1.6.11 Set Output Arming Mode Timing:O.3 Yes/No/ N/A 

2.5.1.8 Manage Pending Configuration File Name 

3.4.1.3.13 Set Pending Configuration File O.1 Yes/No 

Name 

3.4.1.3.14 Get Pending Configuration File O.1 Yes/No 

Name 

2.5.2 Control the TSS 

2.5.2.1 Reset the TSS 

3.4.1.3.1 Restart the TSS M Yes 

3.4.1.3.2 Reinitialize User Settings M Yes 

3.4.1.3.3 Restore Factory Defaults M Yes 

3.4.1.3.4. Retune M Yes 

3.4.1.3.8 Execute Pending Configuration O.1 Yes/No 

3.4.1.3.9 Abort Pending Configuration O.1 Yes/No 

3.4.1.3.10 Validate Pending Configuration O.1 Yes/No 

2.5.2.2 Initiate Sensor Diagnostics 

3.4.1.3.6 Short Diagnostics M Yes 

3.4.1.3.7 Full Diagnostics M Yes 

2.5.2.3 Synchronize the TSS 

3.4.1.3.5 Resynchronize Sampling 

Periods 


2.5.2.4 Update Arming Inputs of the TSS 

3.4.1.3.11 Get External Arming Inputs Timing:O.3 Yes/No/ N/A 

3.4.1.3.12 Set External Arming Inputs Timing:O.3 Yes/No/ N/A 

2.5.2.5 Manage the Camera 

3.4.1.7.1 Set Disable Detection Video:O Yes/No/ N/A 

3.4.1.7.2 Get Disable Detection Video:O Yes/No/ N/A 

3.4.1.7.3 Set the Build Image Parameter Video:O.2 Yes/No/ N/A 

3.4.1.7.4 Set Cancel Build In-Progress Video:O.2 Yes/No/ N/A 





Page 27 

User Need 


User Need 

FR Section 

Number 


Conformance 


Requirement 

3.4.1.7.5 Get Baseline Image Status Video:O.2 Yes/No/ N/A 

3.4.1.7.6 Get Camera Image Formats Video:O.2 Yes/No/ N/A 

Supported 

3.4.1.7.7 Set Image Zone Number Video:O.2 Yes/No/ N/A 

3.4.1.7.8 Get Image Zone Number Video:O.2 Yes/No/ N/A 

3.4.1.7.9 Set Image Type Video:O.2 Yes/No/ N/A 

3.4.1.7.10 Get Image Type Video:O.2 Yes/No/ N/A 

3.4.1.7.11 Set Image Overlay Type Video:O.2 Yes/No/ N/A 

3.4.1.7.12 Get Image Overlay Type Video:O.2 Yes/No/ N/A 

3.4.1.7.13 Set Image Quality Video:O.2 Yes/No/ N/A 

3.4.1.7.14 Get Image Quality Video:O.2 Yes/No/ N/A 

3.4.1.7.15 Set Camera Image Format Video:O.2 Yes/No/ N/A 

3.4.1.7.16 Get Camera Image Format Video:O.2 Yes/No/ N/A 

3.4.1.7.17 Get Camera Name Label Video:O Yes/No/ N/A 

3.4.1.7.18 Set Camera Name Label Video:O Yes/No/ N/A 

3.4.1.7.19 Get Maximum Camera Count Video:M Yes/ N/A 

2.5.2.6 Manage Real Time Clock (RTC) 

3.4.1.4.1 Get Date and Time RTC:M Yes/ N/A 

3.4.1.4.2 Get Daylight Saving Time (DST) RTC:M Yes/ N/A 

Mode 

3.4.1.4.3 Set Date and Time RTC:M Yes/ N/A 

3.4.1.4.4 Set Daylight Saving Time (DST) RTC:M Yes/ N/A 

Mode 

2.5.3 Monitor Current TSS Status 

2.5.3.1 Monitor System Status 

3.4.2.1 Get System Status M Yes 

2.5.3.2 Monitor TSS Sensor Status 

3.4.2.2.1 Get Zone Inductance Loop:M Yes/ N/A 

3.4.2.2.2 Get Zone Frequency Loop:M Yes/ N/A 

3.4.2.2.3 Get Zone Inductance Change Loop:M Yes/ N/A 

3.4.2.2.4 Get Zone Fault History Loop:M Yes/ N/A 

3.4.2.2.5 Get Zone Fault Count Loop:M Yes/ N/A 

3.4.2.2.6 Get Zone Status M Yes 

3.4.2.2.7 Get Image Reception Video:M Yes/ N/A 

Diagnostics 

3.4.2.2.8 Get Image Video:O.2 Yes/No/ N/A 

3.4.2.2.9 Get Zone List for Camera Video:M Yes/ N/A 

3.4.2.2.10 Get Zone Percent Inductance Loop:M Yes/ N/A 

Change 

3.4.2.2.11 Get Image Status Video:O.2 Yes/No/ N/A 


3.4.2.3.1 Get Output Group Output State M Yes 

2.5.3.4 Monitor Zone Status 

3.4.2.2.6 Get Zone Status M Yes 

2.5.4 Collect Data from TSS 

2.5.4.1 Retrieve In-Progress Sample Data 


3.4.3.1.2 Get Historical Sample Volume Sample:M Yes/ N/A 

3.4.3.1.3 Get Historical Sample Percent Sample:M Yes/ N/A 

Occupancy 

3.4.3.1.4 Get Historical Sample Speed Sample:O 

Speed:M 

Yes/No/ N/A 

Yes/ N/A 




Page 28 

User Need 


User Need 

FR Section 

Number 


Conformance 


Requirement 

3.4.3.1.5 Get Historical Sample Zone Sample:M Yes/ N/A 

Status 

3.4.3.1.6 Get Historical Sequence Sample:M Yes/ N/A 

Number 

3.4.3.1.7 Get Zone Class Label Sample:M Yes/ N/A 

3.4.3.1.8 Get Number of Sample Data Sample:M Yes/ N/A 

Entries 

3.4.3.1.9 Get Number of Sensor Zone Sample:M Yes/ N/A 

Classes 

2.5.4.2 Retrieve Current Sample Data 




Occupancy 


Speed:M 

Yes/No/ N/A 

Yes/ N/A 


Status 


Number 



Entries 


Classes 

2.5.4.3 Retrieve Historical Sample Data Sample:M Yes/ N/A 




Occupancy 


Speed:M 

Yes/No/ N/A 

Yes/ N/A 


Status 


Number 



Entries 


Classes 

2.5.5 Multi-Version Interoperability (Backward Compatibility) 





Page 29 

User Need 


2.5.5.1 

(Version01) 

User Need 

FR Section 

Number 


Conformance 


Requirement 


NTCIP 1209:2005 (version v01) Conformance O Yes/No NOTE—Some objects defined in 

NTCIP 1209:2005 (version v01) 

were deprecated and replaced 

by newer objects that have a 

wider scope or have other 

features to ease implementation. 

It is considered the default 

condition for NTCIP 1209:2005 

(version v01) objects to be 

required, the ‘Version1’ 

predicate to be true, and 



the Version1 predicate. 

If the user does not want 

conformance with NTCIP 

1209:2005 (version v01), then 

‘No’ should be in the project 

requirement column and the 

statement below shall be 

checked. 

2.5.5.1.1 Most Recent NTCIP 1209:2005 (version v01) Version1:M Yes/ N/A 

Conformant Data Sample 

3.5.1.1 Get Sample End Time Version1:M Yes/ N/A 

3.5.1.2 Get Volume Version1:M Yes/ N/A 

3.5.1.3 Get Percent Occupancy Version1:M Yes/ N/A 

3.5.1.4 Get Speed Version1:M Yes/ N/A 

3.5.1.5 Get Zone Status Version1:M Yes/ N/A 

2.5.5.1.2 Retrieve NTCIP 1209:2005 (version v01) Conformant Version1:M Yes/ N/A 

Historical Sample Data 

3.5.2.1 Get Sample End Time Version1:M Yes/ N/A 

3.5.2.2 Get Volume Version1:M Yes/ N/A 

3.5.2.3 Get Percent Occupancy Version1:M Yes/ N/A 

3.5.2.4 Get Speed Version1:M Yes/ N/A 

3.5.2.5 Get Zone Status Version1:M Yes/ N/A 

2.5.5.1.3 Loop Output Conditioning Version1:M Yes/ N/A 

3.5.3.1 Get Output Mode Version1:M Yes/ N/A 

3.5.3.2 Get Max Presence Time Version1:M Yes/ N/A 

3.5.3.3 Get Output Delay Time Version1:M Yes/ N/A 

3.5.3.4 Get Output Extend Time Version1:M Yes/ N/A 

3.5.3.5 Get Output Delay Enable Version1:M Yes/ N/A 

3.5.3.6 Get Output Extend Enable Version1:M Yes/ N/A 

3.5.3.7 Set Output Mode Version1:M Yes/ N/A 

3.5.3.8 Set Max Presence Time Version1:M Yes/ N/A 

3.5.3.9 Set Output Delay Time Version1:M Yes/ N/A 

Place a checkmark here 

_______ if the TSS is NOT 

required to support backward 

compatibility with NTCIP 

1209:2005 (version v01). 



Page 30 

User Need 


User Need 

FR Section 

Number 


Conformance 


Requirement 

3.5.3.10 Set Output Extend Time Version1:M Yes/ N/A 

3.5.3.11 Set Output Delay Enable Version1:M Yes/ N/A 

3.5.3.12 Set Output Extend Enable Version1:M Yes/ N/A 


3.3 OPERATIONAL ENVIRONMENT REQUIREMENTS 

Requirements for communications capabilities follow. 

3.3.1 Support Live Data 

Requirements for specifying capabilities of a TSS to provide live data to a TSS management station 

follow. 

3.3.1.1 Retrieve Data 

The TSS shall allow the management stations to retrieve data from the sensor system. 

3.3.1.2 Deliver Data 

The TSS shall allow the management stations to deliver data (e.g., configuration data, commands, etc.) 

to the sensor system. 

3.3.1.3 Data Retrieval and Data Delivery Action Performance 

The TSS shall process SNMP Get/Set/GetNext commands in response to data retrieval and data delivery 

actions performed by the management stations on the TSS in accordance with the performance criteria 

for the SNMP commands established in NTCIP 1103 v02. 

3.3.2 Support Batched Data 

The following requirements define the functions needed to support the exchange of data between the 

TSS management station and the TSS in cases where the TSS is not sharing a live data connection with 

the management stations, but is instead storing data offline for periodic retrieval by the management 

station. 


The TSS shall allow the management stations to retrieve historical sample data from the sensor system. 

3.4 DATA EXCHANGE REQUIREMENTS 

The operation of a TSS has been categorized into three major areas: 

a) Manage the TSS configuration 

b) Monitor the current status of the TSS 

c) Retrieve historical sample data from the TSS 

In Section 2, each of these major areas was broken down into sub-items. The Data Exchange 

Requirements also follow this structure. 

3.4.1 Manage the TSS Configuration 

Requirements for managing TSS configuration follow. 

3.4.1.1 Identify TSS 

Requirements for identifying the TSS follow. 

3.4.1.1.1 Determine Sensor Technology 

The TSS shall allow a management station to determine its sensor technology (such as inductive loop or 




Page 31 

video). This information can then be used to determine if this TSS supports additional data elements that 

are technology specific. 

3.4.1.1.2 Determine Manufacturer 

The TSS shall allow a management station to determine its manufacturer. This shall be as defined in the 

Global Module Object in NTCIP 1201 v03 Section 2.2.3. This information can be useful in creating a TSS 

physical inventory. 

3.4.1.1.3 Determine Model 

The TSS shall allow a management station to determine its model. This shall be as defined in the Global 

Module Object in NTCIP 1201 v03 Section 2.2.3. This information can be useful in creating a TSS 

physical inventory. 

3.4.1.1.4 Determine Firmware Version 

The TSS shall allow a management station to determine its firmware version. This shall be as defined in 

the Global Module Object in NTCIP 1201 v03 Section 2.2.3. This information can be useful in creating a 

TSS physical inventory or determining where firmware upgrades may be needed in the TSS. 

3.4.1.1.5 Determine Hardware Version 

The TSS shall allow a management station to determine its hardware version. This shall be as defined in 

the Global Module Object in NTCIP 1201 v03 Section 2.2.3. This information can be useful in creating a 

TSS physical inventories. 

3.4.1.1.6 Determine Protocol Version 

The TSS shall allow a management station to determine the TSS protocol version that it complies with. 

This shall be as defined in the Global Module Object in NTCIP 1201 v03 Section 2.2.3. This information 

can then be used to determine the correct way of communicating with the TSS. 

3.4.1.1.7 Determine Standards Revision Version 

The TSS shall allow a management station to determine the version of the TSS standard that it conforms 

to. This shall be as defined in the Global Module Object in NTCIP 1201 v03 Section 2.2.3. This 

information can then be used to determine the correct way of communicating with the TSS. 


Requirements for determining capabilities of the TSS follow. 

3.4.1.2.1 Determine Maximum Number of Sensor Zones 

The TSS shall allow a management station to determine the maximum number of sensor zones that the 

TSS supports. This information can then be used to ensure that the management station does not waste 

time querying the TSS for sensor zones that it does not support. 

3.4.1.2.2 Determine Maximum Number of Historical Data Entries per Sensor Zone 

The TSS shall allow a management station to determine the maximum number of historical data entries 

(sample periods) per sensor zone that the TSS supports. All sensor zones shall support the same 

number of sample periods. 

3.4.1.2.3 Determine Maximum Number of Outputs 

The TSS shall allow a management station to determine the maximum number of outputs that the TSS 

supports. This information can then be used to ensure that the management station does not waste time 

querying the TSS for outputs that it does not support. 



Page 32 

3.4.1.2.4 Determine Maximum Number of Output Groups 

The TSS shall allow a management station to determine the maximum number of output groups that the 

TSS supports. This information can then be used to ensure that the management station does not waste 

time querying the TSS for output groups that it does not support. 

3.4.1.2.5 Determine Type of Occupancy Used 

The TSS shall allow a management station to determine the type of occupancy reported by the TSS. This 

information can be useful in determining the correct way to use the occupancy data provided by this TSS. 

3.4.1.2.6 Determine Availability of a Real Time Clock (RTC) 

The TSS shall allow a management station to determine if the TSS has an RTC. This information can 

then be used to determine how to interpret End Time data that is returned for data collection items. If an 

RTC is available, the End Time is the actual date/time when the sample period ended. If an RTC is not 

available, the End Time is the elapsed time since the last power up or reset when the sample period 

ended. 

3.4.1.2.7 Determine if Real Time Clock (RTC) Supports Daylight Saving Time (DST) 

The TSS shall allow a management station to determine if the TSS has an RTC that supports DST. This 

information can then be used to determine how to interpret End Time data that is returned for data 

collection items. If DST is supported, then the End Time is already correct and no further adjustment is 

needed to the returned End Time. If DST is not supported, then the End Time would need to be adjusted 

for DST if appropriate. If an RTC is not available, this item should always return DST as not supported. 

3.4.1.2.8 Determine Maximum Number of Classes 

The TSS shall allow a management station to determine the maximum number of classes that the TSS 

supports. 

3.4.1.2.9 Determine Maximum Number of Characters for Labels 

The TSS shall allow a management station to determine the maximum number of characters for labels 

that the TSS supports. This information can then be used to ensure that the management station does 

not try to send labels that are too long for the TSS to receive. 

3.4.1.2.10 Determine Optional Features 

The TSS shall allow a management station to determine which optional features, if any, that the TSS 

supports. This information can then be used to ensure that the management station does not try to use 

features that are not supported by the TSS. The currently supported optional features are sampling, 

timing, and speed. 

3.4.1.3 Control the TSS 

Requirements for resetting and synchronizing the TSS follow. 

3.4.1.3.1 Restart the TSS 

The TSS shall allow a management station to cause the sensor system to perform a restart that resets 

and initializes the number of seconds since the most recent initialization to zero. This command shall 

perform the same function as cycling power to the TSS. 

3.4.1.3.2 Reinitialize User Settings 

The TSS shall allow a management station to cause the sensor system to reinitialize the user settings to 

their user-defined defaults and flush all historical data. 

3.4.1.3.3 Restore Factory Defaults 

The TSS shall allow a management station to cause the sensor system to reset all settings to preset 




Page 33 

factory defaults. 

3.4.1.3.4 Retune 

The TSS shall allow a management station to cause the sensor system to perform a retune (recalibrate 

unit background settings) for all zones without resetting or flushing of any historical data. 

3.4.1.3.5 Resynchronize Sampling Periods 

The TSS shall allow a management station to cause the sensor system to synchronize all sampling 

period clocks within one second of receiving the command. This command is only needed in TSSs that 

do not support an RTC. This command shall cause the TSS to end all sample periods in-progress, reset 

and initialize the number of seconds since the most recent initialization to zero, and start the next 

sampling period. 

3.4.1.3.6 Short Diagnostics 

The TSS shall allow a management station to cause the sensor system to perform a vendor-specific short 

diagnostic test. This command shall cause the TSS to go through an abbreviated vendor-specific 

diagnostic routine, which may be the same as full diagnostics for some vendors. 

3.4.1.3.7 Full Diagnostics 

The TSS shall allow a management station to cause the sensor system to perform a vendor-specific full 

diagnostic test. This command shall cause the TSS to go through a complete vendor-specific diagnostic 

routine, which may be the same as short diagnostics for some vendors, causing a reset and initialization 

of the number of seconds since the most recent initialization to a value of zero. 

3.4.1.3.8 Execute Pending Configuration 

The TSS shall allow a management station to execute the current uploaded configuration changes that 

may result in a system reboot, system reinitialization, and a loss of historical data. 

3.4.1.3.9 Abort Pending Configuration 

The TSS shall allow a management station to abort the currently pending configuration changes. This 

command shall not result in a system reboot, system reinitialization, or loss of historical data. 

3.4.1.3.10 Validate Pending Configuration 

The TSS shall allow a management station to check the pending configuration file to ensure that it is a 

valid configuration file. 

3.4.1.3.11 Get External Arming Inputs 

The TSS shall allow a management station or other device capable of using this protocol to determine the 

status of the external arming inputs that the TSS supports. This information can then be used to verify 

that the external arming inputs are being activated correctly. 

3.4.1.3.12 Set External Arming Inputs 

The TSS shall allow a management station or other device capable of using this protocol to individually 

set or clear the states of the external arming inputs that the TSS supports. This information can then be 

used to modify the operating characteristics of the TSS. 

3.4.1.3.13 Set Pending Configuration File Name 

The TSS shall allow a management station to set the file name of the file to be used as the next 

configuration file for the TSS. 

3.4.1.3.14 Get Pending Configuration File Name 

The TSS shall allow a management station to get the file name of the file to be used as the next 



Page 34 

configuration file for the TSS. 


Requirements for managing RTC of the TSS follow. 

3.4.1.4.1 Get Date and Time 

The TSS shall allow a management station to get the current sensor system date and time. The sensor 

date and time shall be defined in accordance with the Global Time Object defined in NTCIP 1201 v03 

Section 2.4.1. 

3.4.1.4.2 Get Daylight Saving Time (DST) Mode 

The TSS shall allow a management station to get the current DST mode. The current DST mode shall be 

defined in accordance with the Global Daylight Saving Object defined in NTCIP 1201 v03 Section 2.4.2. 

3.4.1.4.3 Set Date and Time 

The TSS shall allow a management station to set the sensor system date and time to within one second 

of receiving the command. The current date and time shall be defined in accordance with the Global Time 

Object defined in NTCIP 1201 v03 Section 2.4.1. 

3.4.1.4.4 Set Daylight Saving Time (DST) Mode 

The TSS shall allow a management station to set the DST mode. The current time value shall be defined 

in accordance with the Global Daylight Saving Object defined in NTCIP 1201 v03 Section 2.4.2. 

3.4.1.5 Manage Sensor Zones 

Requirements for managing sensor zones of the TSS follow. 

3.4.1.5.1 Get Zone Options 

The TSS shall allow a management station to determine the value of the last ‘Set Zone Options’ 

command. 

3.4.1.5.2 Get Zone Options Status 

The TSS shall allow a management station to determine the current status of zone options. 

3.4.1.5.3 Get Zone Sample Period 

The TSS shall allow a management station to determine the sample period length for a zone. 

3.4.1.5.4 Get Zone Label 

The TSS shall allow a management station to determine the label assigned to a zone. 

3.4.1.5.5 Get Zone Boolean AND Zones 

The TSS shall allow a management station to determine the zones a Boolean AND operation is 

performed on for a zone. 

3.4.1.5.6 Get Zone Boolean OR Zones 

The TSS shall allow a management station to determine the zones a Boolean OR operation is performed 

on for a zone. 

3.4.1.5.7 Set Zone Options 

The TSS shall allow a management station to set zone options. 




Page 35 

3.4.1.5.8 Set Zone Sample Period 

The TSS shall allow a management station to set the sample period of a zone in one minute increments. 

3.4.1.5.9 Set Zone Label 

The TSS shall allow a management station to assign a label to a zone. 

3.4.1.5.10 Set Zone Boolean AND Operator 

The TSS shall allow a management station to set the zones a Boolean AND operation is performed on for 

a zone. 

3.4.1.5.11 Set Zone Boolean OR Operator 

The TSS shall allow a management station to set the zones a Boolean OR operation is performed on for 

a zone. 

3.4.1.5.12 Get Paired Zone 

The TSS shall allow a management station to determine the Paired Zone for a zone. 

3.4.1.5.13 Get Paired Zone Options 

The TSS shall allow a management station to determine the Paired Zone Options for a zone. 

3.4.1.5.14 Get Paired Zone Spacing 

The TSS shall allow a management station to determine the Paired Zone Spacing between a zone and its 

paired zone. 

3.4.1.5.15 Get Speed Correction Factor 

The TSS shall allow a management station to determine the Speed Correction Factor for a zone. 

3.4.1.5.16 Set Paired Zone 

The TSS shall allow a management station to set the Paired Zone for a zone. 

3.4.1.5.17 Set Paired Zone Options 

The TSS shall allow a management station to set the Paired Zone Options for a zone. 

3.4.1.5.18 Set Paired Zone Spacing 

The TSS shall allow a management station to set the Paired Zone Spacing between a zone and its paired 

zone. 

3.4.1.5.19 Set Speed Correction Factor 

The TSS shall allow a management station to set the Speed Correction Factor for a zone. 

3.4.1.5.20 Get Sensor Zone Average Vehicle Length 

The TSS shall allow a management station to get the Sensor Zone Average Vehicle Length. 

3.4.1.5.21 Get Sensor Zone Length 

The TSS shall allow a management station to get the Sensor Zone Length. 

3.4.1.5.22 Set Sensor Zone Average Vehicle Length 

The TSS shall allow a management station to set the Sensor Zone Average Vehicle Length. 



Page 36 

3.4.1.5.23 Set Sensor Zone Length 

The TSS shall allow a management station to set the Sensor Zone Length. 

3.4.1.5.24 Get Sensor Zone Loop Layout 

The TSS shall allow a management station to determine the zone configuration of a TSS zone. This 

information can then be used to ensure that the correct zone configuration has been set for each zone of 

the TSS. 

3.4.1.5.25 Set Sensor Zone Loop Layout 

The TSS shall allow a management station to set the zone configuration of a TSS zone. This information 

can be used by the TSS to determine how to use the information being received from the zone sensor. 

3.4.1.5.26 Set Zone Sensitivity Mode 

The TSS shall allow a management station to set the current sensitivity mode of a zone. 

3.4.1.5.27 Set Zone Sensitivity 

The TSS shall allow a management station to set the current sensitivity of a zone. 

3.4.1.5.28 Set Sensor Zone Frequency Range 

The TSS shall allow a management station to set the frequency range for a sensor zone of a TSS. 

3.4.1.5.29 Get Zone Sensitivity Mode 

The TSS shall allow a management station to determine the current sensitivity mode of a zone. 

3.4.1.5.30 Get Zone Sensitivity 

The TSS shall allow a management station to determine the current sensitivity of a zone. 

3.4.1.5.31 Get Sensor Zone Frequency Range 

The TSS shall allow a management station to determine the frequency range for a sensor zone of a TSS. 

3.4.1.5.32 Get Zone Output Mode 

The TSS shall allow a management station to get the current mode of output. 

3.4.1.5.33 Get Output Max Presence Time 

The TSS shall allow a management station to get the output max presence time. 

3.4.1.5.34 Get Output Delay Time 

The TSS shall allow a management station to get the output delay time. 

3.4.1.5.35 Get Output Extension Time 

The TSS shall allow a management station to get the output extension time. 

3.4.1.5.36 Set Zone Output Mode 

The TSS shall allow a management station to set the output mode. 

3.4.1.5.37 Set Output Max Presence Time 

The TSS shall allow a management station to set the max presence time. 

3.4.1.5.38 Set Output Delay Time 

The TSS shall allow a management station to set the output delay time. 




Page 37 

3.4.1.5.39 Set Output Delay Enables 

The TSS shall allow a management station to set the output delay enables. 

3.4.1.5.40 Set Output Extension Time 

The TSS shall allow a management station to set the output extension time. 

3.4.1.5.41 Set Output Extension Enables 

The TSS shall allow a management station to set the output extension enables. 

3.4.1.5.42 Get Output Delay Mode 

The TSS shall allow a management station to get the output delay mode. 

3.4.1.5.43 Set Output Delay Mode 

The TSS shall allow a management station to set the output delay mode. 

3.4.1.5.44 Get Output Extension Mode 

The TSS shall allow a management station to get the output extension mode. 

3.4.1.5.45 Set Output Extension Mode 

The TSS shall allow a management station to set the output extension mode. 

3.4.1.5.46 Get Zone Output Sequenced 

The TSS shall allow a management station to determine if a zone output is operating in the sequenced 

mode and with which zone it is sequenced. 

3.4.1.5.47 Set Zone Output Sequenced 

The TSS shall allow a management station to set a zone output to operate in the sequenced mode and 

with which zone it is sequenced. 

3.4.1.5.48 Get Output Delay Enables 

The TSS shall allow a management station to determine the output delay enables. 

3.4.1.5.49 Get Output Extension Enables 

The TSS shall allow a management station to determine the output extension enables. 

3.4.1.5.50 Get No Activity Fault Time 

The TSS shall allow a management station to determine the time that a zone is required to go without 

activity to generate a No Activity fault. 

3.4.1.5.51 Get Max Presence Fault Time 

The TSS shall allow a management station to determine the time that a zone goes with continuous 

activity to generate a Max Presence fault. 

3.4.1.5.52 Get Erratic Counts Fault Time 

The TSS shall allow a management station to determine the time that, if a zone’s number of actuations 

meets or exceeds the Erratic Counts Threshold, an Erratic Counts fault is generated. 

3.4.1.5.53 Get Erratic Counts Threshold 

The TSS shall allow a management station to determine the counts that, if a zone’s number of actuations 



Page 38 

meets or exceeds within the Erratic Counts Fault Time, an Erratic Counts fault is generated. 

3.4.1.5.54 Set No Activity Fault Time 

The TSS shall allow a management station to set the time that a zone goes without activity to generate a 

No Activity fault. 

3.4.1.5.55 Set Max Presence Fault Time 

The TSS shall allow a management station to set the time that a zone goes with continuous activity to 

generate a Max Presence fault. 

3.4.1.5.56 Set Erratic Counts Fault Time 

The TSS shall allow a management station to set the time that, if a zone’s number of actuations meets or 

exceeds the Erratic Counts Threshold, an Erratic Counts fault is generated. 

3.4.1.5.57 Set Erratic Counts Threshold 

The TSS shall allow a management station to set the counts that, if a zone’s number of actuations meets 

or exceeds within the Erratic Counts Fault Time, an Erratic Counts fault is generated. 

3.4.1.6 Manage Outputs 

Requirements for managing outputs of the TSS follow. 

3.4.1.6.1 Get Output Sensor Zone 

The TSS shall allow a management station to determine the sensor zone assigned to an output. 

3.4.1.6.2 Get Output Failsafe Mode 

The TSS shall allow a management station to determine the last fail-safe mode command. 

3.4.1.6.3 Get Output Mode Status 

The TSS shall allow a management station to determine the current output mode status of an output. 

3.4.1.6.4 Get Output Label 

The TSS shall allow a management station to determine the label assigned to an output. 

3.4.1.6.5 Set Output Sensor Zone 

The TSS shall allow a management station to set the sensor zone assigned to an output. 

3.4.1.6.6 Set Output Failsafe Mode 

The TSS shall allow a management station to set a fail-safe mode for an output. 

3.4.1.6.7 Set Output Label 

The TSS shall allow a management station to assign a label to an output. 

3.4.1.6.8 Get Output Arming Mode 

The TSS shall allow a management station to get the output arming mode. 

3.4.1.6.9 Set Output Arming Enables 

The TSS shall allow a management station to set the output Arming Enables. 

3.4.1.6.10 Set Output Arming Mode 

The TSS shall allow a management station to set the output arming mode. 




Page 39 

3.4.1.6.11 Get Output Arming Enables 

The TSS shall allow a management station to determine the Arming Enables. 

3.4.1.7 Manage Camera 

Requirements for managing a TSS camera follow. 

3.4.1.7.1 Set Disable Detection 

The TSS shall allow a management station to enable/disable detection on a camera if it is to be used for 

another purpose, such as surveillance, that requires changing its zoom setting. 

3.4.1.7.2 Get Disable Detection 

The TSS shall allow a management station to determine the current detection status of a camera. 

3.4.1.7.3 Set the Build Image Parameter 

The TSS shall allow a management station to instruct the TSS to build an image for FTP transfer. 

3.4.1.7.4 Set Cancel Build In-Progress 

The TSS shall allow a management station to instruct the TSS to cancel an in-progress build of an image 

for FTP transfer. 

3.4.1.7.5 Get Baseline Image Status 

The TSS shall allow a management station to determine if a baseline image is supported and if a 

baseline image is available. 

3.4.1.7.6 Get Camera Image Formats Supported 

The TSS shall allow a management station to determine the image formats supported. 

3.4.1.7.7 Set Image Zone Number 

The TSS shall allow a management station to set the zone that determines which camera's image is built. 

If a TSS contains multiple cameras, the TSS uses this parameter to determine which camera to use to 

build the image. The image built contains the zone specified here. 

3.4.1.7.8 Get Image Zone Number 

The TSS shall allow a management station to determine the zone that determines which camera's image 

is built. 

3.4.1.7.9 Set Image Type 

The TSS shall allow a management station to set the type of image to be built. There are currently two 

supported options: snapshot or baseline. 

3.4.1.7.10 Get Image Type 

The TSS shall allow a management station to determine the type of image to be built. 

3.4.1.7.11 Set Image Overlay Type 

The TSS shall allow a management station to set the overlay to be added to the image to be built. The 

currently supported options are: none, this zone, all zones, or the default overlay. 

3.4.1.7.12 Get Image Overlay Type 

The TSS shall allow a management station to determine the overlay to be added to the image to be built. 



Page 40 

3.4.1.7.13 Set Image Quality 

The TSS shall allow a management station to set the quality of the image to be built. 

3.4.1.7.14 Get Image Quality 

The TSS shall allow a management station to determine the quality of the image to be built. 

3.4.1.7.15 Set Camera Image Format 

The TSS shall allow a management station to set which format is used for the image to be built. 

3.4.1.7.16 Get Camera Image Format 

The TSS shall allow a management station to determine which format is used for the image to be built. 

3.4.1.7.17 Get Camera Name Label 

The TSS shall allow a management station to determine the Name (Label) assigned to a camera. 

3.4.1.7.18 Set Camera Name Label 

The TSS shall allow a management station to assign a Name (Label) to a camera. 

3.4.1.7.19 Get Maximum Camera Count 

The TSS shall allow a management station to determine the maximum number of cameras that the TSS 

supports. This information can then be used to ensure that the management station does not waste time 

querying the TSS for cameras that it does not support. 

3.4.2 Monitor the Current Status 

Requirements for monitoring the current status of the TSS follow. 

3.4.2.1 Get System Status 

The TSS shall allow a management station to determine the overall status of the TSS. 

3.4.2.2 TSS Sensor Status 

Requirements for monitoring sensors of the TSS follow. 

3.4.2.2.1 Get Zone Inductance 

The TSS shall allow a management station to determine the current inductance of the loop/lead-in 

network for a zone. 

3.4.2.2.2 Get Zone Frequency 

The TSS shall allow a management station to determine the current operating frequency of a zone. 

3.4.2.2.3 Get Zone Inductance Change 

The TSS shall allow a management station to determine the change in inductance of a zone. This value 

shall be in nanoHenries. 

3.4.2.2.4 Get Zone Fault History 

The TSS shall allow a management station to determine the fault history of a zone. 

3.4.2.2.5 Get Zone Fault Count 

The TSS shall allow a management station to determine the fault count of a zone. 




Page 41 

3.4.2.2.6 Get Zone Status 

The TSS shall allow a management station to determine the status of a zone. 

3.4.2.2.7 Get Image Reception Diagnostics 

The TSS shall allow a management station to determine if a camera is receiving valid video frames to 

process. 

3.4.2.2.8 Get Image 

The TSS shall allow a management station to retrieve a snapshot from the sensor to verify proper 

operation and if camera movement has occurred. 

3.4.2.2.9 Get Zone List for Camera 

The TSS shall allow a management station to determine which zones are associated with a camera. 

3.4.2.2.10 Get Zone Percent Inductance Change 

The TSS shall allow a management station to determine the change in inductance of a zone. This value 

shall be reported in percent change. 

3.4.2.2.11 Get Image Status 

The TSS shall allow a management station to determine the status of the last request to get an image 

from a camera. 


Requirements for monitoring the output states of the TSS follow. 

3.4.2.3.1 Get Output Group Output State 

The TSS shall allow a management station to determine the on or off states for each output group. 

Output groups are used to compact the data to avoid overloading the communications link. 

3.4.3 Collection of Sample Data 

Requirements for the collection of sample data of the TSS follow. 

3.4.3.1 Retrieve Historical Sample Data from TSS 

Requirements for retrieving historical sample data from the TSS follow. To retrieve data from a particular 

historical sample data period, the zone number, the class, and a prior data entry number are specified. 

3.4.3.1.1 Get Historical Sample End Time 

The TSS shall allow a management station to determine the actual end time of the historical sample data 

period for each zone and class. If an RTC is not available, the number of seconds since the last TSS 

reset is used as a timestamp. 

3.4.3.1.2 Get Historical Sample Volume 

The TSS shall allow a management station to determine the volume of traffic measured for the historical 

sample data period for each zone and class. 

3.4.3.1.3 Get Historical Sample Percent Occupancy 

The TSS shall allow a management station to determine the percent occupancy measured for historical 


3.4.3.1.4 Get Historical Sample Speed 

The TSS shall allow a management station to determine the average speed of traffic measured for the 



Page 42 

historical sample data period for each zone and class. 

3.4.3.1.5 Get Historical Sample Zone Status 

The TSS shall allow a management station to determine the status of the zone during the historical 


3.4.3.1.6 Get Historical Sequence Number 

The TSS shall allow a management station to determine the sequence number of the historical sample 

data period for each zone and class. 

3.4.3.1.7 Get Zone Class Label 

The TSS shall allow a management station to determine the identifying label assigned to a class of a 

zone. 

3.4.3.1.8 Get Number of Sample Data Entries 

The TSS shall allow a management station to determine the number of sample periods that a zone is 

currently using. 

3.4.3.1.9 Get Number of Sensor Zone Classes 

The TSS shall allow a management station to determine the number of classes that a zone is currently 

using. 

3.5 MULTI-VERSION INTEROPERABILITY (MVI-BACKWARD COMPATIBILITY) 

NTCIP 1209 v02 has deprecated three tables that were used in NTCIP 1209:2005 v01. These tables 

have been replaced with new tables that provide additional features and functionality. The TSS shall 

allow Multi-Version Interoperability (MVI-backward compatibility) with NTCIP 1209:2005 v01. 

3.5.1 Retrieve Most Recent NTCIP 1209:2005 (version v01) Conformant Data Sample Table 

Requirements for MVI (backward compatibility) for this table follow. 

3.5.1.1 Get Sample End Time 

The TSS shall allow support of this deprecated object, as indicated in the PRL, to permit MVI when 

necessary to support legacy implementations. 

3.5.1.2 Get Volume 



3.5.1.3 Get Percent Occupancy 



3.5.1.4 Get Speed 



3.5.1.5 Get Zone Status 






Page 43 

3.5.2 Retrieve NTCIP 1209:2005 (version v01) Conformant Historical Sample Data Table 

Requirements for MVI for this table follow. 
















3.5.3 Loop Output Conditioning Table 

Requirements for MVI for this table follow. 

3.5.3.1 Get Output Mode 



3.5.3.2 Get Max Presence Time 



3.5.3.3 Get Output Delay Time 



3.5.3.4 Get Output Extend Time 



3.5.3.5 Get Output Delay Enable 



3.5.3.6 Get Output Extend Enable 





Page 44 

3.5.3.7 Set Output Mode 



3.5.3.8 Set Max Presence Time 



3.5.3.9 Set Output Delay Time 



3.5.3.10 Set Output Extend Time 



3.5.3.11 Set Output Delay Enable 



3.5.3.12 Set Output Extend Enable 






Page 45 

Section 4 

DIALOGS [Normative] 

Section 4 is intended for product developers such as TSS manufacturers and system integrators. Others 

might find Section 4 and Section 5 helpful to gain a greater understanding of design details. 

Section 4 presents the standardized dialogs (i.e., sequence of data exchanges) that fulfill various 

requirements. As SNMP communications are largely driven by the management station, most of the 

requirements define how the TSS responds to various possible actions a management station might take. 

The NTCIP standards effort is based on SNMP. As a protocol, SNMP offers a high degree of flexibility as 

to how the management station structures its request. For example, with SNMP, the management station 

can do any of the following: 

a) Send only those requests that are critical at the current time, whereas a standardized dialog typically 

sends requests relating to all associated data, regardless of whether it is critical for current purposes. 

b) Combine a number of requests in a single packet, whereas a standardized dialog dictates the exact 

contents of each packet. 

c) Separate a group of requests into multiple packets, whereas a standardized dialog dictates the exact 

contents of each packet. 

d) Interweave requests from multiple dialogs, whereas a standardized dialog dictates the exact ordering 

of messages, which are not interrupted with other messages. 

This flexibility can be a powerful tool, allowing a management station to optimize the use of 

communications facilities. This is the primary reason that SNMP was chosen as the core NTCIP protocol; 

however, the flexibility also means that there are numerous allowable variations in the management 

process that a management station may choose to use. 

This flexibility also presents a challenge to ensuring interoperability. While a conformant TSS is required 

to support any allowed sequence in NTCIP 1209 v02, ensuring that a given TSS actually supports every 

possible combination would be impractical. Instead, most agencies only require that the TSS be tested to 

a standard set of procedures, which would use standardized dialogs. Without more extensive testing, a 

management station may attempt to use non-standard dialogs (e.g., to improve communications 

efficiency) against which a TSS has never been tested, which raises the potential for an interoperability 

issue to arise. 

To overcome this, Section 4 defines a lowest common denominator approach to communications 

between a management station and a TSS. Section 4 defines the standardized dialog for each Data 

Exchange Requirement defined in Section 3. Management stations may support other dialogs to fulfill 

these same requirements, as long as these dialogs are consistent with the rules defined in NTCIP 1209 

v02. Such a management station is termed a 'consistent management station'. A consistent management 

station interoperates with any 'conformant' TSS. However, since an agency cannot be certain that a TSS 

is conformant in every possible scenario (given practical constraints), interoperability issues could still 

arise. 



Page 46 

A 'conformant management station' is required to offer a mode in which it only uses the standardized 

dialogs as defined in Section 4. With this limited definition, there is relatively little variability in what 

constitutes a conformant management station, and fully testing a management station for conformance is 

a relatively straightforward process that can be done within the practical constraints faced by most 

agencies. A conformant management station provides an agency with a much greater chance of 

achieving a base level of interoperability with off-the-shelf TSSs that have been tested against NTCIP 

1209 v02. 

The rules for the standardized dialogs follow: 

a) The dialogs are defined by a sequence of GET or SET requests. These requests shall equate to the 

GET and SET operations defined in Sections 4.2.1 and 4.2.3 and shall be transmitted as a single 

message. 

b) The contents of each request are identified by an object name. Each object name consists of an 

object type and an instance identifier. Formal definitions of each object type are provided in Section 5 

and NTCIP 1201 v03. The meaning of the instance identifier is provided by these same definitions 

coupled with standard SNMP rules (see RFC 1212). 

c) Each message shall contain all of the objects as shown, unless otherwise indicated. 

d) A message shall not contain any other objects. 

e) The contents of each message sent by the management station may appear in any order. 

NOTE—Ideally, the order of objects should match the order as shown in NTCIP 1209 v02 to provide 

for the highest probability of interoperability. However, it is recognized that many implementations 

may use off-the-shelf software, which may prevent the designation of an exact ordering of objects 

and as a result, this ordering is not a requirement of NTCIP 1209 v02. 

f) After sending a message, the management station shall not transmit any other data across the 

communications channel until the earlier of: 

1) The management station receiving a response from the device; or 

2) The expiration of the response time. 

g) If the response indicates an error occurred in the operation, the management station shall exit the 

process, unless specific error-handling rules are specified by the dialog. 

h) Dialogs containing a sequence of only GET requests may request objects in any order. 

Finally, Section 4 provides a detailed definition of the required processes to implement the various data 

exchange requirements defined in Section 3. Section 4 is divided into four parts as follows: 

a) Tutorial—provides an overview to better understand the content of this section. 

b) SNMP Interface—defines the formal rules for the generic process by which all data is exchanged 

between the management station and the TSS. 

c) Dialogs—provides the standardized data exchange sequences that can be used by management 

stations to ensure interoperable implementation for the various data exchange requirements 

identified in Section 3.4. 

d) State Tables—provide: 

1) A graphical depiction of the relationship among the various pieces of data; 

2) The formal rules as to which data is supported by a TSS; and 

3) An indication of the operations that may be performed on each piece of data as well as any 

restrictions as to when these operations may be performed. 

NOTE—To fully and clearly describe the design of the system, an object-oriented approach is adopted; 

however, this object-oriented design in no way imposes a requirement for an object-oriented 

implementation. The diagrams shown in NTCIP 1209 v02 are solely intended to show the details of the 

interface logic and static structures; the implementation may follow an object-oriented or structured 

approach. 




Page 47 

4.1 TUTORIAL [INFORMATIVE] 

The Requirements Traceability Matrix (RTM) presented in Annex A identifies the standardized dialog that 

can be used to achieve each of the data exchange requirements defined in Section 3.4. Simple data 

exchange requirements reference one of the generic SNMP dialogs along with a list of data elements. 

These equate to a single message being sent (e.g., a GET request) containing the referenced data 

elements followed by the appropriate response per the generic dialog specification. 

Section 4 defines the standardized dialogs for the more complicated data exchange requirements. Each 

of these dialogs is defined by a number of steps. Many of the steps reference data elements that are 

defined in Section 5. These data elements are also shown in the corresponding row of the RTM with their 

precise section number. 

The dialogs may also be accompanied by an informative figure that provides a graphical depiction of the 

normative text. The figures conform to the Uniform Modeling Language (UML) and depict the 

management station as an outside actor sending a series of messages to the TSS and the TSS returning 

responses. If there is any conflict between the figure and the text, the text takes precedence. 

Section 4.2 defines the generic processes used in subsequent discussions as to how data is exchanged. 

The diagrams used in this section are the same type as described below. 

Section 4.3 defines how the system is designed to work for a given data exchange requirement. Section 

4.3 indicates the sequence of actions that a management station is required to follow to provide the 

specific service, and this is typically shown through a sequence diagram. A solid line with an arrowhead 

indicates initiation of a request from one entity to another (e.g., typically the management station to the 

TSS). A dashed-line with an arrowhead indicates a return value to a request (i.e., the TSS to the 

management station). Generally, the entities that initiate requests are on the left of those receiving the 

request. The flow of events can be followed by looking at the message lines between objects as they 

move across and down the page. An example sequence diagram is provided in Figure 2. 

:Managemen 

t Station 

:TSS 

(Precondition) The management station 

shall determine the number of outputs and 

the number of sensor zones supported by 

the TSS. 

outputConfig.a is a structure containing 

the following data: 

a) Sensor zone number 

b) Failsafe mode 

c) Mode status 

d) Label 

Where a = output to configure. 

Set() 

outputConfig.a 

Figure 2 Sample Sequence Diagram for Output Configuration 



Page 48 

In addition to sequence diagrams for a given dialog, there may also be a View of Participating Classes 

(VOPC) diagram that depicts the interrelationships among the various entities identified in the sequence 

diagrams. For a vast majority of cases, the dialogs for a TSS are simplistic enough to be described in 

simple list form without sequence or class diagrams. 

4.2 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) INTERFACE 

To promote interoperability, NTCIP 1209 v02 requires support for the Simple Network Management 

Protocol (SNMP). Section 4.2 defines how the management station and TSS shall respond to each 

request using SNMP. 

The TSS shall conform to the requirements for the Simple Network Management Protocol (SNMP) as 

defined in NTCIP 1103. Sections 4.2.1 through 4.2.4 provide a description of the key services offered by 

SNMP assuming no errors; precise rules and procedures are defined in NTCIP 1103. Section 4.2.5 

extends the requirements of NTCIP 1103 by providing additional requirements that supplement but do not 

replace any requirements of NTCIP 1103. 

4.2.1 Generic SNMP Get Interface 

SNMP defines a generic process by which a management station can retrieve data from a TSS. This 

process consists of a Get request (GET) and a GetResponse as depicted in Figure 3. Both the Get 

request and the GetResponse messages contain a list of objects as defined by the varBindingList 

structure (see Section 4.2.4). 

: 

Statio 

Get(varBindingList 

GetResponse(varBindingList 

: TSS 

Figure 3 SNMP Get Interface 

This generic process is customized by subsequent sections of NTCIP 1209 v02, by referencing the 'GET' 

operation, and directly by the RTM, by section number, to fulfill a wide range of the requirements defined 

in Section 3. 

4.2.2 Generic SNMP Get-Next Interface 

SNMP defines a process by which a management station can explore data within a TSS. This process 

consists of a GetNext request and a GetResponse as depicted in Figure 4. Both the GetNext request and 

the GetResponse messages contain a list of objects as defined by the varBindingList structure (see 

Section 4.2.4). 




Page 49 

: 

Statio 

GetNext(varBindingList 


: TSS 

Figure 4 SNMP GetNext Interface 

4.2.3 Generic SNMP Set Interface 

SNMP defines a generic process by which a management station can send data to a TSS. This process 

consists of a Set request and a GetResponse as depicted in Figure 5. Both the Set request and the 

GetResponse messages contain a list of objects as defined by the varBindingList structure (see Section 

4.2.4). 

: 

Statio 

Set(varBindingList 


: TSS 

Figure 5 SNMP Set Interface 

NOTE—The response message issued to an SNMP Set request is the same message structure as used 

to respond to an SNMP Get request. The SNMP standard calls this response message a GetResponse, 

but it is in fact a response to either a GET or a SET. 

This generic process is customized by subsequent sections of this standard, by referencing the 'SET' 

operation, and directly by the RTM, by section number, to fulfill a wide range of the requirements defined 

in Section 3. 



Page 50 

4.2.4 Variable Binding List Structure 

The requests and responses for the Get, Get Next, and Set operations all use the varBindingList 

structure. NTCIP 1103 v02 defines this structure as containing zero or more varBindings, where each 

varBinding is defined to consist of an object name (as indicated by an Object Identifier (OID)) and the 

associated object value. This is relationship is depicted in Figure 6. 

Figure 6 SNMP Interface—View of Participating Classes 

4.2.5 Additional Requirements 

4.2.5.1 Grouping of Objects in a Request 

The TSS shall allow the management station to perform a single Get, GetNext, or Set operation on any 

combination of supported objects with the objects listed in any order within the message, unless 

otherwise restricted by NTCIP 1209 v02. 

The TSS shall not associate any semantics to the ordering of objects within the varBindingsList. As 

required by RFC 1157, Clause 4.1.5, each object shall be affected "as if simultaneously set with respect 

to all other assignments specified in the same message." 

4.2.5.2 Support of Get 

The TSS shall allow the management station to perform the Get operation on any supported object for 

which support for the Get Operation is indicated in Section 4.2.1. 

4.2.5.3 Support of GetNext 

The TSS shall allow the management station to perform the GetNext operation on any OBJECT 

IDENTIFIER. 

4.2.5.4 Support of Set 

The TSS shall allow the management station to perform the Set operation on any supported object for 

which support for the Set Operation is indicated in Section 4.2.3. 

4.2.5.5 Performance 

The TSS shall process the Get, GetNext, or Set request in accordance with all of the rules of NTCIP 1103 

v02, including updating the value in the database and initiating the transmission of the appropriate 

response (assuming that the TSS has permission to transmit) within 1 second of receiving the last byte of 

the request. 

4.3 SPECIFIED DIALOGS 

Section 4.3 provides the standardized data exchange sequences that can be used by management 

stations to ensure interoperable implementations for the various data exchange requirements identified in 

Section 3.4. 




Page 51 

4.3.1 Managing the TSS Configuration 

Standardized dialogs for managing the TSS configuration are defined in the following subsections. 

4.3.1.1 Reset and Synchronize the TSS 

The standardized dialog for a management station to restart, reinitialize, restore, retune, re-sync, run 

short diagnostics or long diagnostics of a TSS shall be as follows: 

a) (Precondition) None 

b) The management station shall GET the sensorSystemStatus.x state. If the state of 

sensorSystemStatus is 'initializing', 'pendingConfigurationChange', or 

'validatingPendingConfiguration', then the management station shall abort the process 

c) The management station shall SET the sensorSystemReset.y state to 'restart', 

'reinitializeUserSettings', 'restoreFactoryDefaults', 'retune', 'resyncSamplingPeriods', 

'shortDiagnostics', or 'fullDiagnostics' 

d) The management station shall GET the sensorSystemStatus.x state 

e) If the management station gets no response, then repeat Step d up to maximum TSS initialization 

time 

f) If the sensorSystemStatus.x state is 'initializing', then repeat Step d 

g) If sensorSystemStatus.x state is 'oK', then the TSS reset is complete 

h) If sensorSystemStatus.x state NOT 'oK', then the reset may not have completed, did not complete 

normally, or an error was encountered during the process. The management station shall abort the 

process 

Where: 

x = sensorSystemStatus 

y = sensorSystemReset 

4.3.1.2 Send a Configuration File 

The standardized dialog for a management station to send and execute a configuration change shall be 

as follows: 

a) (Precondition) None 

b) The management station may FTP a Configuration File to the TSS 

c) The management station may set pendingConfigurationFileName to the desired configuration file to 

execute 

d) Complete normally the Validate Pending Configuration process 

e) Complete normally the Execute Pending Configuration Change process 

4.3.1.3 Execute Pending Configuration Change 

The standardized dialog for a management station to execute a pending configuration change shall be as 

follows: 

a) (Precondition) The management station has completed normally the Validate Pending Configuration 

process 


sensorSystemStatus is NOT 'pendingConfigurationChange', then the management station shall abort 

the process 

c) The management station shall SET sensorSystemReset.y state to 'executePendingConfiguration' 

d) The management station shall GET the sensorSytemStatus.x state 

e) If the management station gets no response, then repeat Step d up to maximum TSS initialization 

time 

f) If the sensorSystemStatus.x state is 'initializing', then repeat Step d 

g) If the sensorSystemStatus.x state is 'oK', then the new configuration is complete 



Page 52 

h) If the sensorSystemStatus.x state is NOT 'oK', then the Execute Pending Configuration Change may 

not have completed, did not complete normally, or an error was encountered during the process. The 

management station shall abort the process 

Where: 



4.3.1.4 Abort Pending Configuration 

The standardized dialog for a management station to abort a pending configuration change shall be as 

follows: 

a) (Precondition) The management station has completed normally the Validate Pending Configuration 

process 


sensorSystemStatus is NOT 'pendingConfigurationChange', then the management station shall abort 

the process 

c) The management station shall SET the sensorSystemReset.y state to 'abortPendingConfiguration. 

The abort pending configuration is then complete 

Where: 



4.3.1.5 Validate a Pending Configuration 

The standardized dialog for a management station to validate a configuration file (i.e., ensure that the file 

is a valid configuration file) shall be as follows: 

a) (Precondition) The management station should have transferred the new configuration file prior to 

requesting it be validated. This is to ensure that the management station knows what configuration 

file is being validated by the TSS 


sensorSystemStatus is 'diagnosticError', then the management station shall abort the process 

c) The management station shall SET sensorSystemReset.y state to 'validatePendingConfiguration' 

d) The management station shall GET the sensorSytemStatus.x state 

e) If the sensorSystemStatus.x state is 'validatingPendingConfiguration', then repeat Step d 

f) If the sensorSystemStatus.x state is 'pendingConfigurationChange', then the new configuration is 

valid and ready to execute 

g) If the sensorSystemStatus.x state is 'pendingConfigurationError', then the new configuration is not 

valid and cannot be executed 

h) If the sensorSystemStatus.x state is NOT 'pendingConfigurationChange' or 

'pendingConfigurationError', then the Validate Pending Configuration may not have completed, did 

not complete normally, or an error was encountered during the process. The management station 

shall abort the process 

Where: 



4.3.1.6 Configure a Sensor Zone 

The standardized dialog for a management station to configure a sensor zone shall be as follows: 

a) (Precondition) The management station shall determine that the sensorZoneNumber is less than or 

equal to maxSensorZones. For a management station to set a label, the optional sensorZoneLabel is 

supported and label length is less than or equal to maximumNumberOfCharacters. For the 




Page 53 

management station to set sensorZoneSamplePeriod, the TSS supports sampling features. For the 

management station to set sensorZonePairedZone, sensorZonePairedZoneOptions, 

sensorZonePairedZoneSpacing, sensorZoneSpeedCorrectionFactor, sensorZoneAvgVehicleLength, 

or sensorZoneLength, the TSS supports speed features 

b) The management station shall SET the following data to the desired values: 

1) sensorZoneOptions.x 

2) sensorZoneOptionsStatus.x 

3) sensorZoneSamplePeriod.x 

4) sensorZoneLabel.x 

5) sensorZoneAndOperator.x 

6) sensorZoneOrOperator.x 

7) sensorZonePairedZone.x 

8) sensorZonePairedZoneOptions.x 

9) sensorZonePairedZoneSpacing.x 

10) sensorZoneSpeedCorrectionFactor.x 

11) sensorZoneAvgVehicleLength.x 

12) sensorZoneLength.x 

13) sensorZoneNoActivityFaultTime.x 

14) sensorZoneMaxPresenceFaultTime.x 

15) sensorZoneErraticCountsFaultTime.x 

16) sensorZoneErraticCountsThreshold.x 

c) Repeat Step b for each sensor zone to be modified 

d) If no additional sensorZoneEntry parameters to set, then configuring sensorZoneEntry is complete 

Where: 

x = sensorZoneNumber 

4.3.1.7 Retrieve a Sensor Zone Configuration 

The standardized dialog for a management station to retrieve a configuration for a sensor zone shall be 

as follows: 


equal to maxSensorZones. For a management station to get a label, the optional sensorZoneLabel is 

supported. For the management station to get sensorZoneSamplePeriod, the TSS supports sampling 

features. For the management station to get sensorZonePairedZone, 

sensorZonePairedZoneOptions, sensorZonePairedZoneSpacing, 

sensorZoneSpeedCorrectionFactor, sensorZoneAvgVehicleLength, or sensorZoneLength, the TSS 

supports speed features 

b) The management station shall GET the following desired data: 

1) sensorZoneNumber.x 

2) sensorZoneOptions.x 

3) sensorZoneOptionsStatus.x 

4) sensorZoneSamplePeriod.x 

5) sensorZoneLabel.x 

6) sensorZoneAndOperator.x 

7) sensorZoneOrOperator.x 

8) sensorZonePairedZone.x 

9) sensorZonePairedZoneOptions.x 

10) sensorZonePairedZoneSpacing.x 

11) sensorZoneSpeedCorrectionFactor.x 

12) sensorZoneAvgVehicleLength.x 

13) sensorZoneLength.x 

14) sensorZoneStatus.x 

15) sensorZoneNoActivityFaultTime.x 

16) sensorZoneMaxPresenceFaultTime.x 



Page 54 

17) sensorZoneErraticCountsFaultTime.x 

18) sensorZoneErraticCountsThreshold.x 

c) Repeat Step b for each sensor zone that it is desired to retrieve data from 

d) If no additional sensorZoneEntry parameters to get, then retrieving sensorZoneEntry configuration is 

complete 

Where: 


4.3.1.8 Configuring External Arming Inputs 

The standardized dialog for a management station to configure the external arming inputs of a TSS shall 

be as follows: 

a) (Precondition) The TSS to be configured shall support timing features. The TSS also supports the 

optional external arming inputs. 

b) The management station shall SET externalArmingInputs. 

c) Configuring of external arming inputs is complete. 

NOTE—Only bits with a value of one (1) have any effect. This allows multiple management stations to 

control specific arming inputs. Bits to be controlled by each management station are required to be set to 

OFF or set to ON. Therefore, for any input there are four possible settings: (OFF:0 ON:0 = No Change, 

OFF:1 ON:0 = Set to Off, OFF:0 ON:1 = Set to On, and OFF:1 ON:1 = Not Valid—in this case, the set to 

Off shall take precedence). 

4.3.1.9 Retrieve External Arming Inputs 

The standardized dialog for a management station to retrieve the configuration of the external arming 

inputs of a TSS shall be as follows: 

a) (Precondition) The TSS to be configured shall support timing features. The TSS also supports the 

optional external arming inputs. 

b) The management station shall GET externalArmingInputs. 

c) Retrieval of external arming inputs is complete. 

NOTE—Arming inputs that are set to OFF have their OFF bits set to one (1). Arming inputs that are set to 

ON have their ON bits set to one (1). 

4.3.1.10 Configure Sensor Zone Output Conditioning 

The standardized dialog for a management station to configure the sensor zone output conditioning of a 

TSS shall be as follows: 


equal to maxSensorZones. For the management station to set sensorZoneMaxPresenceTime, 

sensorZoneOutputDelayTime, or sensorZoneOutputExtendTime, the TSS supports timing features. 

For the management station to set sensorZoneOutputDelayMode, sensorZoneOutputDelayEnables, 

sensorZoneOutputExtendMode, or sensorZoneOutputExtendEnables, the TSS supports the optional 

External Arming Inputs or the optional Arming Pins. For the management station to set 

sensorZoneOutputSequenced, the TSS supports this optional feature 


1) outputConditioningEntry:sensorZoneOutputMode.x 

2) outputConditioningEntry:sensorZoneMaxPresenceTime.x 

3) outputConditioningEntry:sensorZoneOutputDelayTime.x 

4) outputConditioningEntry:sensorZoneOutputDelayMode.x 

5) outputConditioningEntry:sensorZoneOutputDelayEnables.x 

6) outputConditioningEntry:sensorZoneOutputExtendTime.x 

7) outputConditioningEntry:sensorZoneOutputExtendMode.x 




Page 55 

8) outputConditioningEntry:sensorZoneOutputExtendEnables.x 

9) outputConditioningEntry:sensorZoneOutputSequenced.x 

c) Repeat Step b for each sensor zone to be modified 

Where: 


4.3.1.11 Retrieve Sensor Zone Output Conditioning 

The standardized dialog for a management station to retrieve the sensor zone output conditioning of a 



equal to maxSensorZones. For the management station to get sensorZoneMaxPresenceTime, 

sensorZoneOutputDelayTime, or sensorZoneOutputExtendTime, the TSS supports timing features. 

For the management station to get sensorZoneOutputDelayMode, sensorZoneOutputDelayEnables, 

sensorZoneOutputExtendMode, or sensorZoneOutputExtendEnables, the TSS supports the optional 

External Arming Inputs or the optional Arming Pins. For the management station to get 

sensorZoneOutputSequenced, the TSS supports this optional feature 

b) The management station shall GET the following desired settings: 

1) outputConditioningEntry:sensorZoneNumber.x 

2) outputConditioningEntry:sensorZoneOutputMode.x 

3) outputConditioningEntry:sensorZoneMaxPresenceTime.x 

4) outputConditioningEntry:sensorZoneOutputDelayTime.x 

5) outputConditioningEntry:sensorZoneOutputDelayMode.x 

6) outputConditioningEntry:sensorZoneOutputDelayEnables.x 

7) outputConditioningEntry:sensorZoneOutputExtendTime.x 

8) outputConditioningEntry:sensorZoneOutputExtendMode.x 

9) outputConditioningEntry:sensorZoneOutputExtendEnables.x 

10) outputConditioningEntry:sensorZoneOutputSequenced.x 

c) Repeat Step b for each sensor zone to be retrieved 

Where: 


4.3.1.12 Configure Loop Output Conditioning for a Sensor Zone 

This dialog accesses objects that are now deprecated and is included to provide MVI. See Section 

4.3.1.10 for the preferred dialog and objects. 

The standardized dialog for a management station to configure the loop output conditioning for a sensor 

zone shall be as follows: 


equal to maxSensorZones. The TSS supports sampling features 


1) LoopOutputConditioningEntry:zoneOutputMode.x 

2) LoopOutputConditioningEntry:zoneMaxPresenceTime.x 

3) LoopOutputConditioningEntry:zoneOutputDelayTime.x 

4) LoopOutputConditioningEntry:zoneOutputExtendTime.x 

5) LoopOutputConditioningEntry:zoneOutputExtendEnable.x 

6) LoopOutputConditioningEntry:zoneOutputDelayEnable.x 

c) Repeat Step b for each sample data item to be retrieved 

d) Retrieval of the loop output conditioning for a sensor zone is complete 

Where: 




Page 56 

4.3.1.13 Retrieve Loop Output Conditioning for a Sensor Zone 



The standardized dialog for a management station to retrieve the loop output conditioning for a sensor 





1) LoopOutputConditioningEntry:zoneOutputMode.x 

2) LoopOutputConditioningEntry:zoneMaxPresenceTime.x 

3) LoopOutputConditioningEntry:zoneOutputDelayTime.x 

4) LoopOutputConditioningEntry:zoneOutputExtendTime.x 

5) LoopOutputConditioningEntry:zoneOutputExtendEnable.x 

6) LoopOutputConditioningEntry:zoneOutputDelayEnable.x 


d) Retrieval of the loop output conditioning for a sensor zone is complete 

Where: 


4.3.2 Monitoring the Status of the TSS 

Standardized dialogs for monitoring the TSS configuration that are more complex than simple GETs or 

SETs are defined as follows. 

4.3.2.1 Configure Output 

The standardized dialog for a management station to configure the output configuration of a TSS shall be 

as follows: 

a) (Precondition) The management station shall determine that the outputNumber is less than or equal 

to maxOutputNumber. For a management station to set outputLabel, the TSS supports the optional 

outputLabel, and label length is less than or equal to maximumNumberOfCharacters. For the 

management station to set outputArmingEnables or outputArmingMode, the TSS supports the 

optional External Arming Inputs or the optional Arming Pins 


1) outputConfigurationEntry:outputSensorZoneNumber.x 

2) outputConfigurationEntry:outputFailsafeMode.x 

3) outputConfigurationEntry:outputModeStatus.x 

4) outputConfigurationEntry:outputLabel.x 

5) outputConfigurationEntry:outputArmingEnables.x 

6) outputConfigurationEntry:outputArmingMode.x 

c) Repeat Step b for each output number to be modified 

Where: 

x = outputNumber 

4.3.2.2 Retrieve Output Configuration 

The standardized dialog for a management station to retrieve the output configuration of a TSS shall be 

as follows: 

a) (Precondition) The management station shall determine that the outputNumber is less than or equal 

to maxOutputNumber. For a management station to get outputLabel, the TSS supports the optional 




Page 57 

outputLabel. For the management station to get outputArmingEnables or outputArmingMode, the 

TSS supports the optional External Arming Inputs or the optional Arming Pins 


1) outputConfigurationEntry:outputSensorZoneNumber.x 

2) outputConfigurationEntry:outputFailsafeMode.x 

3) outputConfigurationEntry:outputModeStatus.x 

4) outputConfigurationEntry:outputLabel.x 

5) outputConfigurationEntry:outputArmingEnables.x 

6) outputConfigurationEntry:outputArmingMode.x 

c) Repeat Step 2 for each output number to be retrieved 

Where: 

x = outputNumber 

4.3.2.3 Retrieve Output Group 

The standardized dialog for a management station to retrieve an output group of a TSS shall be as 

follows: 

a) (Precondition) The management station shall determine that the outputGroupNumber is less than or 

equal to maxOutputGroups 


1) outputConfigurationEntry:outputGroupNumber.x 

2) outputConfigurationEntry:outputGroupState.x 

c) Repeat Step b for each output group number to be retrieved 

Where: 

x = outputGroupNumber 

4.3.3 Retrieving Sample Data from TSS 

Standardized dialogs for retrieving sample data from the TSS that are more complex than simple GETs or 

SETs are defined in the following subsections. 

4.3.3.1 Retrieve Sensor Zone Sequence Parameters 

The standardized dialog for a management station to retrieve the sensor zone sequence parameters for a 





1) zoneSequenceEntry:numSampleDataEntries.x 

2) zoneSequenceEntry:numSensorZoneClass.x 

c) Repeat Step b for each sensor zone number to be retrieved 

Where: 


4.3.3.2 Retrieve Sample Data for a Particular Sensor Zone, Sample Entry, and Zone Class 

The standardized dialog for a management station to retrieve the sample data for a particular sensor 

zone, sample entry, and zone class for a TSS shall be as follows: 


equal to maxSensorZones. The management station shall determine that the sampleEntryNum is 

less than or equal to numSampleDataEntries. The management station shall determine that the 

sampleZoneClass is less than or equal to numSensorZoneClass. The TSS supports sampling 



Page 58 

features 

b) The management station shall GET and remember the value of 

sampleDataEntry:sampleSequenceNumber.z.y.x 

c) The management station shall GET the following desired data: 

1) sampleDataEntry:sampleEndTime.z.y.x 

2) sampleDataEntry:sampleVolumeData.z.y.x 

3) sampleDataEntry:samplePercentOccupancy.z.y.x 

4) sampleDataEntry:sampleSpeedData.z.y.x 

5) sampleDataEntry:sampleZoneStatus.z.y.x 

6) sampleDataEntry:sampleSequenceNumber.z.y.x 

d) Repeat Step c for each sample data item to be retrieved 

e) The management station shall GET and remember the value of 


f) If the value from Step b is not the same as the value in Step e, then all data is not from the intended 

sample period (the buffer scrolled sometime during the read cycle). Discard the data that was read. If 

sampleEntryNum is less than or equal to zoneSequenceEntry:numSampleDataEntries, then 

sampleEntryNum = sampleEntryNum + 1 and go to Step b (this rereads the data from its new 

location) else abort (the data for that sample period is lost) 

g) Get is complete 

Where: 


y = sampleEntryNum 

z = sampleZoneClass 

4.3.3.3 Retrieve All Sample Data for a Sensor Zone 

The standardized dialog for a management station to retrieve the sensor zone sample data for a TSS 

shall be as follows: 



b) The management station shall GET zoneSequenceEntry:numSampleDataEntries.x and 

zoneSequenceEntry:numSensorZoneClass.x 

c) sampleEntryNum = zoneSequenceEntry:numSampleDataEntries.x from Step b 

d) sampleZoneClass = zoneSequenceEntry:numSensorZoneClass.x from Step b 



f) The management station shall GET the following desired data: 







g) Repeat Step f for each sample data item to be retrieved 

h) If sampleZoneClass is greater than 0, then sampleZoneClass = sampleZoneClass - 1 and go to 

Step f 

i) The management station shall GET and remember the value of 


j) If the value from Step e is not the same as the value in Step i, then all data is not from the same 

sample period (the buffer scrolled sometime during the read cycle). Discard the data that was read 

for the current sampleEntryNum. If sampleEntryNum is less than or equal to 

zoneSequenceEntry:numSampleDataEntries, then sampleEntryNum = sampleEntryNum + 1, 

sampleZoneClass = zoneSequenceEntry:numSensorZoneClass.x from Step b, and go to Step d (this 

rereads the data from its new location) else discard all data read for this sampleEntryNum for this 




Page 59 

sampleZoneNumber and go to Step c (the data for that sample period for that sample zone number is 

lost) 

k) If sampleDataEntryNum is greater than 1 then sampleDataEntryNum = sampleDataEntryNum - 1 and 

go to Step d 

l) Retrieval of all sample data for a sensor zone is complete 

Where: 




NOTE—Reading of sample data starts from the oldest entry to the newest to try and read the oldest data 

before it is scrolled out of the buffer. 

4.3.3.4 Retrieve In-Progress Sample Data for a Sensor Zone [INFORMATIVE] 

The standardized dialog for a management station to retrieve the sensor zone sample data for the 

sample currently in-progress for a TSS shall be as follows: 



b) The management station shall GET zoneSequenceEntry:numSensorZoneClass.x 

c) sampleEntryNum = 0 

d) sampleZoneClass = zoneSequenceEntry:numSensorZoneClass.x from Step b 



f) The management station shall GET the following desired data: 







g) Repeat Step f for each sample data item to be retrieved 

h) If sampleZoneClass is greater than 0 then sampleZoneClass = sampleZoneClass - 1 and go to Step f 

i) The management station shall GET and save the value of 


j) If the value from Step e is not the same as the value in Step i, then all data is not from the same 

sample period (the buffer scrolled sometime during the read cycle). Discard the data that was read 

for the current sampleEntryNum. If the sample period that just completed is the data of interest, set 

sampleEntryNum = 1 and go to Step d. The in-progress sample period contains very little data if the 

buffer just scrolled. If this data is desired go to Step c else exit 

k) Retrieval of the in-progress sample data for the sensor zone is complete 

Where: 




4.3.3.5 Retrieve Sensor Zone Class Labels 

The standardized dialog for a management station to retrieve the class labels for a sensor zone shall be 

as follows: 


equal to the maxSensorZones. The TSS supports sampling features 

b) The management station shall GET zoneSequenceEntry:numSensorZoneClass.x 



Page 60 

c) sampleZoneClass = zoneSequenceEntry:numSensorZoneClass.x from Step b 

d) The management station shall GET zoneClassLabel.y.x 

e) If zoneClassEntry is greater than 0, then zoneClassEntry = zoneClassEntry - 1 and go to Step d 

f) Retrieval of class labels for this sensor zone is complete 

Where: 

x = zoneClassEntry 

y = sampleZoneClass 

4.3.3.6 Retrieve NTCIP 1209:2005 (version v01) Conformant Most Recent Data Sample for a 

Sensor Zone 


4.3.3.2 Retrieve Sample Data for a Particular Sensor Zone, Sample Entry, and Zone Class for the 

preferred dialog and objects. 

The standardized dialog for a management station to retrieve the most recent data sample for a sensor 





1) DataCollectionEntry:endTime.x 

2) DataCollectionEntry:volumeData.x 

3) DataCollectionEntry:percentOccupancy.x 

4) DataCollectionEntry:speedData.x 

5) DataCollectionEntry:zoneStatus.x 


d) Retrieval of the most recent data sample for the sensor zone is complete 

Where: 


4.3.3.7 Retrieve NTCIP 1209:2005 (version v01) Conformant Historical Sample Data for a Sensor 

Zone 



The standardized dialog for a management station to retrieve the historical sample data for a sensor zone 

shall be as follows: 

a) (Precondition) The management station shall be aware that the sensorZoneNumber is less than or 



1) DataBufferEntry:endTimeBuffer.x 

2) DataBufferEntry:volumeDataBuffer.x 

3) DataBufferEntry:percentOccupancyBuffer.x 

4) DataBufferEntry:speedDataBuffer.x 

5) DataBufferEntry:zoneStatusBuffer.x 


d) Retrieval of the data buffer for the sensor zone is complete 

Where: 





Page 61 

4.3.4 Managing the Inductive Loop Features of the TSS 

Standardized dialogs for managing the Inductive Loop features of the TSS that are more complex than 

simple GETs or SETs are defined in the following subsections. 

4.3.4.1 Configure Loop System Setup Parameters 

The standardized dialog for a management station to configure the loop senor setup parameters for 

sensor zones shall be as follows: 


equal to maxSensorZones. The sensorTechnology is inductiveLoop 

b) The management station shall SET the following objects to the desired values for each 

sensorZoneNumber: 

1) zoneSensitivity.x 

2) zoneSensitivityMode.x 

3) zoneFrequencyRange.x 

4) sensorZoneLoopLayout.x 

c) If additional loop sensor setup data needs to be entered for additional sensorZoneNumbers repeat 

Step b 

d) If no additional data is to be entered for additional sensorZoneNumber's then SET is complete 

Where: 


4.3.4.2 Retrieve Loop System Setup Parameters 

The standardized dialog for a management station to retrieve the loop sensor setup parameters for 

sensor zones shall be as follows: 


equal to maxSensorZones. The sensorTechnology is inductiveLoop 

b) The management station shall GET the following objects values for each sensorZoneNumber: 

1) zoneSensitivity.x 

2) zoneSensitivityMode.x 

3) zoneFrequencyRange.x 

4) sensorZoneLoopLayout.x 

c) If additional loop sensor setup data needs to be retrieved for additional sensorZoneNumbers, repeat 

Step b 

d) If no additional data is to be entered for additional sensorZoneNumbers, then GET is complete 

Where: 


4.3.4.3 Retrieve Loop System Status 

The standardized dialog for a management station to retrieve the loop system status parameters for a 

loop sensor shall be as follows: 


equal to maxSensorZones. The sensorTechnology value is also set to inductiveLoop 

b) The management station shall GET the following objects values for each sensorZoneNumber: 

1) zoneInductance.x 

2) zoneFrequency.x 

3) zoneInductanceChange.x 

4) zonePercentInductanceChange.x 

5) zoneFaultHistory.x 

6) zoneFaultCount.x 



Page 62 

7) sensorZoneNumber.x 

c) If additional loop system status data needs to be retrieved for additional sensorZoneNumbers, repeat 

Step b 

d) If no additional data is to be retrieved for additional sensorZoneNumbers, then GET is complete 

Where: 


4.3.5 Managing the Machine Vision Features of the TSS 

Standardized dialogs for managing the Machine Vision features of the TSS that are more complex than 

simple GETs or SETs are defined in the following subsections. 

4.3.5.1 Set the Build Image Parameter 

The standardized dialog for a management station to set the Build Image parameter for a machine vision 

TSS sensor shall be as follows: 

a) (Precondition) The sensorTechnology type shall be machineVision. The management station shall 

determine that the sensorZoneNumber is less than or equal to maxSensorZones. SensorZone as 

used in this dialog is from one camera only. The desired format of the image is a supported format, 

either jpeg or bitmap. If the management station sets imageType equal to ‘snapshot’, then 

snapshotImage is be supported by the camera. If the management station sets imageType equal to 

‘baseline’, then baselineImage is supported and available. For the management station to set the 

imageOverlayType, the imageOverlayType is be supported 

b) The management station shall SET the desired value for the following objects: 

1) imageZoneNumber.x 

2) imageType.x 

3) imageOverlayType.x 

4) imageFormat.x 

5) imageQuality.x 

c) The management station shall SET the value of buildImageCmd to 'buildImage' 

d) The management station shall GET the value of buildImageStatus.x 

1) If the value of buildImageStatus.x is 'buildingImage' or 'buildPending' then to abort 

buildImageCmd the management station shall SET the value of buildImageCmd to 

'cancelBuildInProgress'. The management station shall then repeat Step c 

2) If buildImageStatus.x is NOT 'imageReady', then an error has occurred and the value returned 

indicates the type of error encountered 

3) If buildImageStatus.x is 'imageReady', then the management station can retrieve the image via 

FTP 

4) If the management station needs to build other images, then go to Step b else Build Image is 

complete 

Where: 


4.3.5.2 Set Cancel Build In-Progress 

The standardized dialog for a management station to cancel a build in-progress for a camera shall be as 

follows: 

a) (Precondition) The value of sensorTechnology shall be machineVision. The management station 

shall determine that buildImageStatus.x is equal to either 'buildingImage' or 'buildPending' 

b) The management station shall SET the value of buildImageCmd.x to 'cancelBuildInProgress' 

c) Cancel Build in-Progress is complete 

Where: 





Page 63 

4.4 STATE TABLES 

4.4.1 State Transitions for sensorSystemStatus 

The TSS powers up in the ‘initializing‘ state. 

Current State Command or Event Result 

1—other 

2—oK 

3—initializing 

TSS begins operating normally 

Received one of the following commands: 

sensorSystemReset:restart 

sensorSystemReset:reinitializeUserSettings 

sensorSystemReset:restoreFactoryDefaults 

sensorSystemReset.retune 

sensorSystemReset.resyncSamplingPeriods 

sensorSystemReset.shortDiagnostics 

sensorSystemReset.fullDiagnostics 

Received 

sensorSystemReset:validatePendingConfiguration 

Hardware fault detected in the TSS 

While operating, an error is detected by the TSS in 

the active configuration 

The TSS is not operating normally and cannot 

transition to any of the other defined states 

Received one of the following commands: 








sensorSystemReset.executePendingConfiguration 

Received 



While operating, an error is detected by the TSS in 




Initializing has completed successfully 

2—oK 


5— 

validatingPendingConfig 

uration 

6—diagError 

7—activeConfigError 

1—other 

3—Initializing 

5— 


uration 

6—diagError 


1—other 

2—oK 



Page 64 


4— 

pendingConfiguration 

Change 

5— 

validatingPendingCo 

nfiguration 

6—diagError 


While initializing, an error is detected by the TSS in 


The TSS received a 

sensorSystemReset:abortPendingConfiguration and 

the TSS is operating normally. 

The TSS did not receive a 

sensorSystemReset:executePendingConfiguration 

command before the manufacturer specified time to 

complete the configuration expired 


sensorSystemReset:executePendingConfiguration. 

If any other sensorSystemReset commands should 

be run, either an abort or execute is required to be 

completed first 



sensorSystemReset.abortPendingConfiguration and 

a fault is detected in the active configuration file 



the TSS is operating normally 

The TSS has validated the pending configuration 

file and found no errors in it. It is now ready to 

execute 




the current configuration file has a fault detected 

The TSS has validated the pending configuration file 

and found it to contain errors. The file cannot be 

executed 

The manufacturer may specify whether the TSS 

may return to normal operation if the error clears. 

This depends on the type of error 

6—diagError 


2—oK 


6—diagError 


2—oK 

5— 

pendingConfigurationCh 

ange 

6—diagError 


8—pendingConfigError 

2—oK 




Page 65 



8— 

pendingConfigError 

Received one of the following commands to try and 

clear the error: 










The active configuration error was corrected at the 

TSS using the local user interface 

Received one of the following commands to try and 

clear the error: 



Received 





the TSS is operating normally 




the current configuration file has a fault detected 


1—other 

2—oK 


5— 


uration 

6—diagError 

2—oK 

6—diagError 


4.4.1.1 Other State 

When in the other state, the following rules shall apply: 

a) The TSS shall process the following sensorSystemReset commands: 

1) sensorSystemReset:restart 

2) sensorSystemReset:reinitializeUserSettings 

3) sensorSystemReset:restoreFactoryDefaults 

4) sensorSystemReset:retune 

5) sensorSystemReset:resyncSamplingPeriods 

6) sensorSystemReset:shortDiagnostics 

7) sensorSystemReset:fullDiagnostics 

8) sensorSystemReset:validatePendingConfiguration 

b) The TSS shall not enter this state if the state can also transition to one of the following: 

1) pendingConfigurationChange 

2) validatingPendingConfiguration 



Page 66 

3) diagError 

4) activeConfigError 

5) pendingConfigError 

4.4.1.2 OK State 

When in the OK state, the following rule shall apply: 










4.4.1.3 Initializing State 

When in the initializing state, the following rules shall apply: 

a) The TSS shall reject all sensorSystemReset commands 

b) Once initializing is complete, the sensorSystemStatus shall transition to ‘oK’ if successful 

c) If initialization is not successful, the state may be set to diagnostic error, active configuration error, or 

other 

4.4.1.4 Pending Configuration Change State 

When in the pending configuration change state, the following rules shall apply: 


1) sensorSystemReset.executePendingConfiguration 

2) sensorSystemReset:abortPendingConfiguration 

If other commands need to be sent, an abort shall be sent first 

b) If the TSS receives a sensorSystemReset.abortPendingConfiguration or the manufacturer-specified 

time to wait for the execution has passed, the pending configuration change shall be aborted and the 

TSS shall return to the previous state 

c) If the TSS receives a sensorSystemReset.executePendingConfiguration, the TSS shall transition to 

the initializing state and begin the manufacturer-specific initialization steps 

4.4.1.5 Validating Pending Configuration State 

When in the validating pending configuration state, the following rules shall apply: 



If other commands need to be sent, an abort is required to be sent first 

b) Once the TSS successfully validates the pending configuration file, the state may change to pending 

configuration change 

c) If the validation found a fault in the pending configuration file, the state may change to pending 

configuration error 

4.4.1.6 Diagnostic Error State 

When in the diagnostic error state, the following rules shall apply: 






Page 67 







b) Depending upon the manufacturer and the specific error that occurred, the TSS may return to ‘oK’ 

state if the error clears 

c) The TSS shall remain in the diagnostic error state if an active configuration error also exists until one 

of the sensorSystemReset commands is issued 

4.4.1.7 Active Configuration Error State 

When in the active configuration error state, the following rules shall apply: 







b) The error may be cleared at the TSS. If this happens, the state transitions to ‘oK’ 

4.4.1.8 Pending Configuration Error State 

When in the pending configuration error state, the following rules shall apply: 



If other commands need to be sent, an abort is sent first 

b) If the TSS receives a sensorSystemReset:abortPendingConfiguration command, the TSS returns to 

the previous state 



Page 68 

Section 5 

MANAGEMENT INFORMATION BASE (MIB) 

[Normative] 

Section 5 defines those objects that are expected to be used by transportation sensor systems (TSS). 

The objects are presented using the OBJECT-TYPE macro as specified in RFC 1212 and NTCIP 8004 

v02. The text provided from Section 5.1 through the end of Section 5 (except the section headings) 

constitutes the NTCIP 1209 v02 Standard TSS MIB. 

This is an architecture that is a proposed component for the National ITS Architecture. The architecture 

diagram identifies some of the terms and acronyms described above, in addition to identifying the focus 

of NTCIP 1209 v02. The tree structure identifies how the data element definitions are combined under 

specific nodes. See Annex B for a figure that provides a pictorial representation of the TSS Branch and 

Tree Structure. 

In general, Section 5 presents the objects in lexigraphical order of their OBJECT IDENTIFIERS, which 

correspond to their physical location within the global naming tree. Most of the objects defined in NTCIP 

1209 v02 reside under the ‘tss’ node of the global naming tree. To aid in object management, the ‘tss’ 

node has been subdivided into logical categories, each defined by a node under the ‘tss’ node. The 

individual objects are then located under the appropriate node. 

Conformance requirements for any object are determined by the use of the Requirements Traceability 

Matrix (RTM) in Annex A. To support any defined Requirement, an implementation shall support all 

objects to which the Requirement traces in the RTM. The value of the STATUS field for every object in 

the MIB is ‘mandatory’, and indicates that it is mandatory if any associated Requirement is selected. 

For all bitmapped objects, if a bit is zero (0), then the referenced function is disabled or not supported, 

and if a bit is one (1), then the referenced function is enabled or supported. 

The full standardized range of all objects defined in NTCIP 1209 v02 shall be supported, except as 

otherwise noted. This MIB is managed by the NTCIP TSS Working Group and proprietary features should 

be defined through vendor-specific nodes in vendor-specific extensions to this MIB. All values not 

explicitly defined (e.g., enumerated values not listed, bits not defined, etc.) are reserved for future use by 

the TSS Working Group. 

5.1 TRANSPORTATION SENSOR SYSTEM OBJECTS 

--*************************************************************************** 

-- Filename: NTCIP1209v0217.mib 

-- Description: This MIB defines the object definitions for transportation 

-- sensor systems (TSS) 

-- Source: NTCIP 1209v0217 

-- MIB Revision History: 

-- 2005 NTCIP 1209:2005 v01 approved 

-- 2008 Completed 1209 TSS Version v02 drafting 

-- 2010..........edited for publication 

-- 

-- Copyright 2010, 2003-2008 by the American Association of State Highway 

-- and Transportation Officials (AASHTO), the Institute of Transportation 

-- Engineers (ITE), and the National Electrical Manufacturers Association 

-- (NEMA). All intellectual property rights, including but not limited to, 

-- the rights of reproduction, translation and display are reserved under the 

-- laws of the United States of America, the Universal Copyright Convention 

-- the Berne Convention, and the International and Pan-American Copyright 

Copy Per MIB Distribution Permission 



Page 69 

-- Conventions. Except as licensed and permitted, you may not copy these 

-- materials without prior written permission from AASHTO, ITE, or NEMA. 

-- Use of these materials does not give you any rights of ownership or 

-- claim of copyright in or to these materials. 

-- 

-- Joint NEMA, AASHTO, and ITE 

-- NTCIP Management Information Base 

-- DISTRIBUTION NOTICE 

-- 

-- To the extent that these materials are distributed by AASHTO / ITE / NEMA 

-- in the form of a Data Dictionary ("DD") or Management Information Base 

-- ("MIB"), AASHTO / ITE / NEMA extend the following permission: 

-- You may make and / or distribute unlimited copies, including derivative 

-- works, of the DD or MIB, including copies for commercial distribution, 

-- provided that: 

-- (i) each copy you make and / or distribute contains the citation "Derived 

-- from NTCIP 0000 [insert the document number]. Used by permission of AASHTO 

-- / ITE / NEMA."; 

-- (ii) the copies or derivative works are not made part of the standards 

-- publications or works offered by other standards developing organizations 

-- or publishers or as works-for-hire not associated with commercial hardware 

-- or software products intended for field implementation; 

-- (iii) use of the DD or MIB is restricted in that the syntax fields may be 

-- modified only to reflect a more restrictive subrange or enumerated value; 

-- (iv) the description field may be modified but only to the extent that: 

-- (a) only those bit values or enumerated values that are supported are 

-- listed; and (b) the more restrictive subrange is expressed. 

-- 

-- These materials are delivered "AS IS" without any warranties as to their 

-- use or performance. 

-- 

-- AASHTO / ITE / NEMA and their suppliers do not warrant the performance 

-- or results you may obtain by using these materials. AASHTO / ITE / NEMA 

-- and their suppliers make no warranties, express or implied, as to 

-- noninfringement of third party rights, merchantability, or fitness for any 

-- particular purpose. In no event will AASHTO / ITE / NEMA or their 

-- suppliers be liable to you or any third party for any claim or for any 

-- consequential, incidental or special damages, including any lost profits 

-- or lost savings, arising from your reproduction or use of these materials, 

-- even if an AASHTO / ITE / NEMA representative has been advised of the 

-- possibility of such damages. 

-- 

-- Some states or jurisdictions do not allow the exclusion or limitation of 

-- incidental, consequential or special damages, or the exclusion of implied 

-- warranties, so the above limitations may not apply to you. 

-- 

-- Use of these materials does not constitute an endorsement or affiliation by 

-- or between AASHTO, ITE, or NEMA and you, your company, or your products and 

-- services. 

-- 

-- If you are unwilling to accept the foregoing restrictions, you should 

-- immediately return these materials. 

-- 

-- NTCIP is a trademark of AASHTO / ITE / NEMA. 

--**************************************************************************** 

NTCIP1209v02-MIB1 DEFINITIONS::= BEGIN 

IMPORTS 

© 2010 AASHTO / ITE / NEMA Copy Per MIB Distribution Permission


Page 70 

IpAddress, Counter 

FROM RFC1155-SMI 

OBJECT-TYPE 

FROM RFC-1212 

DisplayString 

FROM RFC1213-MIB 

OwnerString, BITMAP8, BITMAP16, BITMAP32, tss 

FROM NTCIP8004 v02 

-- Additional textual conventions. 

BITMAP64 ::= OCTET STRING (SIZE (8)) 



-- For the purpose of this section, the following OBJECT IDENTIFIERS 

-- are used: 

-- the node location is: nema / transportation 

5.2 SENSOR CONFIGURATION AND CAPABILITY OBJECTS 

tssSystemSetup OBJECT IDENTIFIER ::= { tss 1 } 

-- This node is an identifier used to group all objects for TSS sensor 

-- configurations that are common to all TSS. 

5.2.1 Sensor Reset, Resynchronization, and Diagnostics 

sensorSystemReset OBJECT-TYPE 

SYNTAX INTEGER { 

restart (1), 

reinitializeUserSettings (2), 

restoreFactoryDefaults (3), 

retune (4), 

resyncSamplingPeriods (5), 

shortDiagnostics (6), 

fullDiagnostics (7), 

executePendingConfiguration (8), 

abortPendingConfiguration (9), 

validatePendingConfiguration (10), 

noResetInProgress (11) 

} 

ACCESS read-write 

STATUS mandatory 

DESCRIPTION 

" A software interface to initiate a reset of various functions of 

the TSS. Execution of the command shall set this object to the value 0. 

The reset commands are described as follows: 

restart(1) - This command shall cause the unit to enter restart state 

and go through a complete shut-down and start-up process, causing a 

reset and initialization of the number of seconds since most recent 

TSS initialization to a value of zero. 

reinitializeUserSettings(2) – This command shall cause the unit to flush 

all memory and reinitialize all settings to their user-defined default 

values, and reset and initialize the number of seconds since most recent 

TSS initialization to a value of zero. 

restoreFactoryDefaults(3) - This command shall cause the unit to flush 

all memory, restore all settings to their factory default values, and 

reset and initialize the number of seconds since most recent TSS 

initialization to a value of zero. 




Page 71 

retune(4) – This command recalibrates unit background settings for all 

zones without resetting or flushing of any collected data. 

resyncSamplingPeriods(5) – This command shall cause the unit to 

synchronize all startup sampling period clocks within one (1) second of 

receiving the command and a reset and initialize of the number of 

seconds since most recent TSS initialization to a value of zero. 

shortDiagnostics(6) – This command shall cause the unit to go through 

an abbreviated vendor-specific diagnostic routine which may be the same 

as full diagnostics for some vendors. 

fullDiagnostics(7) – This command shall cause the unit to go through 

a complete vendor-specific diagnostic routine which may be the same as 

short diagnostics for some vendors, causing a reset and initialization 

of the number of seconds since most recent TSS initialization to a 

value of zero. 

executePendingConfiguration(8) – The behavior of this command is 

dependent upon type of configuration file uploaded and is manufacturerspecific. 

Execution may result in a system reboot, reinitialization, 

and loss of historical data. 

abortPendingConfiguration(9) – This command shall cause the TSS 

to cancel the currently pending configuration changes. 

validatePendingConfiguration(10) – This command is used to check the 

configuration to ensure that it is a valid configuration file. 

noResetInProgress(11) – No command is in-progress. All other commands 

shall set this object to this state upon completion. This value is 

read-only. 

1.3.6.1.4.1.1206.4.2.4.1.1" 

::= { tssSystemSetup 1 } 

5.2.2 Sensor System Status 

sensorSystemStatus OBJECT-TYPE 


other (1), 

oK (2), 

initializing (3), 

pendingConfigurationChange (4), 

validatingPendingConfiguration (5), 

diagError (6), 

activeConfigError (7), 

pendingConfigError (8) } 

ACCESS read-only 


DESCRIPTION 

"This data element provides an indication of the overall sensor 

system status, as follows: 

other(1) - Indicates the presence of a hardware or software status that 

is not designated as either OK or initializing; 

oK(2) - Indicates that the unit is operating normally with no known 

hardware of software faults, with no implications about data; 

initializing(3) - Indicates that the unit has encountered no fault, but 

is not ready for detection. 

pendingConfigurationChange(4) - Indicates there is a new configuration 

that is implemented in the TSS upon the executePendingConfiguration 

command. 

validatingPendingConfiguration (5) - Indicates that the TSS is 

checking that the downloaded file is a valid configuration file. 

diagError (6) - Indicates that a hardware malfunction has been 

identified. 



Page 72 

activeConfigError (7) - Indicates that the current configuration being 

used in the TSS is invalid. 

pendingConfigError (8) - Indicates that the pending configuration file 

is invalid. 

1.3.6.1.4.1.1206.4.2.4.1.2" 


5.2.3 Sensor System Occupancy Type 

sensorSystemOccupancyType OBJECT-TYPE 


normalizedOtherOccupancy (1), 

nonNormalizedOccupancy (2), 

zoneOccupancy (3), 

normalizedSixFootLoopOccupancy (4), 

normalizedTwoMeterLoopOccupancy (5), 

normalizedPointOccupancy (6)} 



DESCRIPTION 

" Indicates how to interpret the occupancy data of this TSS. 

normalizedOtherOccupancy(1) - Occupancy is normalized to other 

specific criteria that is not defined by other enumerated entries of 

this data element. Use of this enumeration should be done carefully 

as it could effect interoperability of equipment. 

nonNormalizedOccupancy(2) - Occupancy is presented as non-normalized or 

raw occupancy data. 

zoneOccupancy(3) - Occupancy is presented for a given zone. 

normalizedSixFootLoopOccupancy(4) - Occupancy is normalized to a 6-foot 

by 6-foot loop. 

normalizedTwoMeterLoopOccupancy(5) - Occupancy is normalized to a 2- 

meter by 2-meter loop. 

normalizedPointOccupancy(6) - Occupancy is normalized to a point. 

1.3.6.1.4.1.1206.4.2.4.1.3" 


5.2.4 Maximum Number of Sensor Zones Parameter 

maxSensorZones OBJECT-TYPE 

SYNTAX INTEGER (1..255) 



DESCRIPTION 

" Indicates the maximum number of sensor zones supported by this 

TSS. 

1.3.6.1.4.1.1206.4.2.4.1.4" 


5.2.5 Sensor Zone Table 

sensorZoneTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SensorZoneEntry 

ACCESS not-accessible 


DESCRIPTION 

" A table containing sensor zone unit parameters. The number of 

rows in this table is equal to the maxSensorZones data element. Table rows are 

set by the manufacturer, and row creation/deletion is not supported. 

static 

1.3.6.1.4.1.1206.4.2.4.1.5" 

::= { tssSystemSetup 5} 




Page 73 

sensorZoneEntry OBJECT-TYPE 

SYNTAX SensorZoneEntry 



DESCRIPTION 

" Table for sensor zone parameters." 

INDEX { sensorZoneNumber } 

::= { sensorZoneTable 1 } 

SensorZoneEntry ::= SEQUENCE { 

sensorZoneNumber 

sensorZoneOptions 

sensorZoneOptionsStatus 

sensorZoneSamplePeriod 

sensorZoneLabel 

sensorZoneAndOperator 

sensorZoneOrOperator 

sensorZonePairedZone 

sensorZonePairedZoneOptions 

sensorZonePairedZoneSpacing 

sensorZoneSpeedCorrectionFactor 

sensorZoneAvgVehicleLength 

sensorZoneLength 

sensorZoneStatus 

sensorZoneNoActivityFaultTime 

sensorZoneMaxPresenceFaultTime 

sensorZoneErraticCountsFaultTime 

sensorZoneErraticCountsThreshold 

} 

INTEGER, 

BITMAP8, 

BITMAP8, 

INTEGER, 

OCTET STRING, 

BITMAP64, 

BITMAP64, 

INTEGER, 

BITMAP8, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER, 

INTEGER 

5.2.5.1 Sensor Zone Number 

sensorZoneNumber OBJECT-TYPE 




DESCRIPTION 

" The numerical label or number of the sensor zone. This value 

shall not exceed the maxSensorZones data element value. sensorZoneNumber is 

used as an index for various data element tables. 

1.3.6.1.4.1.1206.4.2.4.1.5.1.1" 

::= { sensorZoneEntry 1 } 

5.2.5.2 Sensor Zone Options 

sensorZoneOptions OBJECT-TYPE 

SYNTAX BITMAP8 



DESCRIPTION 

" A bit-mapped value as defined below for commanding this sensor 

zone to be ENABLED or DISABLED. A non-configured system shall default to 

DISABLED. 

 

bit 7 0=DISABLED, 1=ENABLED To command this sensor zone to be enabled or 

disabled; 

bits 6..0 

Reserved (bit 0=LSB) 

1.3.6.1.4.1.1206.4.2.4.1.5.1.2" 



Page 74 


5.2.5.3 Sensor Zone Options Status 

sensorZoneOptionsStatus OBJECT-TYPE 




DESCRIPTION 

" A bit-mapped value as defined below for indicating the status of 

whether this sensor zone is ENABLED or DISABLED. A zones options status may be 

disabled even though the status is set to enabled. This can occur if the 

sensor has automatically disabled a zone. Example: The TSS is a camera that 

has Pan/Tilt/Zoom control and the camera is temporarily moved for a 

surveillance operation. All of the zones on this camera would be automatically 

disabled until the camera had been returned to its original position. 

 

bit 7 0=DISABLED, 1=ENABLED To indicate the status of this sensor zone; 

bits 6..0 

Reserved (bit 0=LSB). 

1.3.6.1.4.1.1206.4.2.4.1.5.1.3" 


5.2.5.4 Sensor Zone Sample Period Parameter 

sensorZoneSamplePeriod OBJECT-TYPE 




DESCRIPTION 

" Duration of the sample period in seconds for the sensor zone 

over which time data is collected. Sample period durations from 0 to 3600 are 

available for use. Values from 3601.to.65535 are reserved for future use. A 

sampling period of zero (0) means that data is not being collected, while the 

sensor zone may continue to be enabled. 

second 

1.3.6.1.4.1.1206.4.2.4.1.5.1.4" 

DEFVAL { 0 } 


5.2.5.5 Sensor Zone Label 

sensorZoneLabel OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE(8..255)) 


STATUS optional 

DESCRIPTION 

" A text string used to describe the TSS sensor zone. A maximum 

string length of less than 255 may be supported. 

1.3.6.1.4.1.1206.4.2.4.1.5.1.5" 


5.2.5.6 Sensor Zone Boolean AND Operator 

sensorZoneAndOperator OBJECT-TYPE 




DESCRIPTION 

" This data element identifies up to eight (8) unique zones that 

can be sequentially combined with a Boolean AND command to provide an input to 

this zone, as follows: 




Page 75 

 

Byte 1 Sensor zone number for the first Boolean AND combined with this zone, 

Byte 2 Sensor zone number for the second Boolean AND combined with this zone, 

Byte 3 Sensor zone number for the third Boolean AND combined with this zone, 

Byte 4 Sensor zone number for the fourth Boolean AND combined with this zone, 

Byte 5 Sensor zone number for the fifth Boolean AND combined with this zone, 

Byte 6 Sensor zone number for the sixth Boolean AND combined with this zone, 

Byte 7 Sensor zone number for the seventh Boolean AND combined with this 

zone, 

Byte 8 Sensor zone number for the eighth Boolean AND combined with this zone. 

Boolean AND combinations are processed before Boolean OR combinations. When 

read, this object returns last value written. 

-- This was TSS.orOperator:text in version v01. 

-- Corrected this typo because orOperator:text is used below. 

1.3.6.1.4.1.1206.4.2.4.1.5.1.6" 


5.2.5.7 Sensor Zone Boolean OR Operator 

sensorZoneOrOperator OBJECT-TYPE 




DESCRIPTION 

" This data element identifies up to eight (8) unique zones that 

can be sequentially combined with a Boolean OR command to provide an input to 

this zone, as follows: 

 

Byte 1 Sensor zone number for the first Boolean OR combined with this zone, 

Byte 2 Sensor zone number for the second Boolean OR combined with this zone, 

Byte 3 Sensor zone number for the third Boolean OR combined with this zone, 

Byte 4 Sensor zone number for the fourth Boolean OR combined with this zone, 

Byte 5 Sensor zone number for the fifth Boolean OR combined with this zone, 

Byte 6 Sensor zone number for the sixth Boolean OR combined with this zone, 

Byte 7 Sensor zone number for the seventh Boolean OR combined with this zone, 

Byte 8 Sensor zone number for the eighth Boolean OR combined with this zone. 

Boolean AND combinations are processed before Boolean OR combinations. When 

read, this object returns last value written. 

1.3.6.1.4.1.1206.4.2.4.1.5.1.7" 


5.2.5.8 Sensor Zone Paired Zone 

sensorZonePairedZone OBJECT-TYPE 




DESCRIPTION 

" This is a zone that provides additional information to the 

current zone for features that require a sequenced second zone to determine 

direction of travel or time of travel (e.g., speed trap, wrong way, etc.) 

1.3.6.1.4.1.1206.4.2.4.1.5.1.8" 


5.2.5.9 Sensor Zone Paired Zone Options 

sensorZonePairedZoneOptions OBJECT-TYPE 




DESCRIPTION 



Page 76 

" A bit-mapped value as defined below for indicating the status of 

the options for a paired zone. 

 

bit 0 0=OFF, 1=ON For a Sensor Zone operating in pairs the Zone 

Placement Option ON indicates that the zone is 

the leading zone of the pair and Zone Placement 

Option OFF indicates that the zone is a trailing 

zone in the pair. 

bit 1 0=OFF, 1=ON For a Sensor Zone operating in pairs the Single 

Zone Speed Mode Option is only used when there 

is an error on one of the paired zones. This 

parameter identifies how the TSS should 

calculate speed without the other zone. OFF 

indicates a manufacturer specific calculation 

and a Single Zone Speed Mode Option ON indicates 

the use of the calculation Speed = (Average 

Vehicle Length + Zone Length) / Detect Time. 

1.3.6.1.4.1.1206.4.2.4.1.5.1.9" 


5.2.5.10 Sensor Zone Paired Zone Spacing 

sensorZonePairedZoneSpacing OBJECT-TYPE 




DESCRIPTION 

" This parameter allows the user to set the spacing between paired 

zones for use in calculating vehicle speeds. This parameter is usually 

measured from the leading edge of one zone to the leading edge of the paired 

zone. 

1.3.6.1.4.1.1206.4.2.4.1.5.1.10" 


5.2.5.11 Sensor Zone Speed Correction Factor 

sensorZoneSpeedCorrectionFactor OBJECT-TYPE 




DESCRIPTION 

" This is a percent multiplier for speed calculations within the 

TSS that is used to fine tune the accuracy of the reported speed. A setting of 

1000 would be a multiplier of 1.000. 

one one-thousandth of a percent 

1.3.6.1.4.1.1206.4.2.4.1.5.1.11" 


5.2.5.12 Sensor Zone Average Vehicle Length 

sensorZoneAvgVehicleLength OBJECT-TYPE 




DESCRIPTION 

" This parameter allows the user to set the average vehicle length 

for use in determining speed and classification. This allows for a range of 

lengths between 0.01 meters to 40 meters in length 

one-hundredth of a meter 

1.3.6.1.4.1.1206.4.2.4.1.5.1.12" 




Page 77 

::= { sensorZoneEntry 12} 

5.2.5.13 Sensor Zone Length Parameter 

sensorZoneLength OBJECT-TYPE 

SYNTAX INTEGER (1..4000 | 65535) 



DESCRIPTION 

" This parameter allows the user to set the length of the sensor 

zone. The value of 65535 shall be returned to represent no zone length set. 

This allows for a range of lengths between 0.01 meters to 40 meters in length. 

one-hundredth of a meter 

1.3.6.1.4.1.1206.4.2.4.1.5.1.13" 


5.2.5.14 Sensor Zone Status 

sensorZoneStatus OBJECT-TYPE 


other (1), 

oK (2), 


noActivity (4), 

maxPresence (5), 

configurationError (6), 

erraticCounts (7), 

disabled (8), 

overrideActive (9), 

sensorFailure (10), 

inputDataIntegrity (11), 

poorContrast (12), 

detectionAutoSuspended (13), 

pairedZoneFault (14) } 



DESCRIPTION 

" Detailed status returned as result of diagnostics, as follows: 

Value Meaning 

other(1) - Indicates an error has occurred within the TSS for which 

there is no defined definition within this data element, 

oK(2) - Indicates no other status values apply, 

initializing(3) - Indicates an initialization or diagnostics procedure 

is in-progress, 

noActivity(4) - Indicates no activity condition, 

maxPresence(5) - Indicates max presence condition, 

configurationError(6) - Indicates an error within the TSS 

configuration setup, 

erraticCounts(7 )- Indicates erratic counts, 

disabled(8) - Indicates that the zone is disabled. 

overrideActive(9) - Indicates an override is active. 

sensorFailure(10) - Indicates a sensing element failure. 

inputDataIntegrity(11) - Indicates input values are not sufficient to 

determine detector data accurately (e.g., bad communications, invalid 

video for machine vision) 

poorContrast(12) - Indicates insufficient contrast error condition. 

detectionAutoSuspended(13) - Indicates that the detection zone was 

automatically disabled by the TSS (e.g., camera is on a PTZ and 

was moved). 

pairedZoneFault(14) - Indicates that there was no problem with this 



Page 78 

zone, but a zone that it is paired with had a fault. This may affect 

the accuracy of data reported by this zone. 

If a condition occurs during the sample period, then that state remains for 

the duration of that sample period. If multiple conditions occur during a 

sample period, the last reported condition, other than OK, is retained. 

1.3.6.1.4.1.1206.4.2.4.1.5.1.14" 


5.2.5.15 Sensor Zone No Activity Fault Time 

sensorZoneNoActivityFaultTime OBJECT-TYPE 




DESCRIPTION 

" Time period in seconds for the sensor zone during which, if 

there is no activity for the zone, a No Activity status is generated for the 

zone. A no activity fault time of zero (0) means that a no activity status 

cannot be generated for this sensor zone. 

second 

1.3.6.1.4.1.1206.4.2.4.1.5.1.15" 

DEFVAL { 0 } 


5.2.5.16 Sensor Zone Max Presence Fault Time 

sensorZoneMaxPresenceFaultTime OBJECT-TYPE 




DESCRIPTION 

" Time period in seconds for the sensor zone during which, if 

there is constant activity for the zone, a Max Presence status is generated 

for the zone. A max presence fault time of zero (0) means that a max presence 

status can not be generated for this sensor zone. 

second 

1.3.6.1.4.1.1206.4.2.4.1.5.1.16" 

DEFVAL { 0 } 


5.2.5.17 Sensor Zone Erratic Counts Fault Time 

sensorZoneErraticCountsFaultTime OBJECT-TYPE 




DESCRIPTION 

" Time period in seconds for the sensor zone during which, if the 

Erratic Counts Threshold is created for the zone, an Erratic Counts status is 

generated for the zone. An erratic counts fault time of zero (0) means that an 

erratic counts status can not be generated for this sensor zone. 

second 

1.3.6.1.4.1.1206.4.2.4.1.5.1.17" 

DEFVAL { 0 } 


5.2.5.18 Sensor Zone Erratic Counts Threshold 

sensorZoneErraticCountsThreshold OBJECT-TYPE 






Page 79 


DESCRIPTION 

" The counts that if a sensor zone’s number of actuations meets or 

exceeds within the Erratic Counts Fault Time an Erratic Counts status is 

generated for the zone. An erratic counts threshold of zero (0) means that an 

erratic counts status can not be generated for this sensor zone. 

count 

1.3.6.1.4.1.1206.4.2.4.1.5.1.18" 

DEFVAL { 0 } 


5.2.6 Clock Available 

clockAvailable OBJECT-TYPE 


clockYes (1), 

clockNo (2) } 



DESCRIPTION 

" Indicates availability of a real time clock within the TSS so 

that time can be referenced to CTime. 

clockYes(1) - A real time clock is provided within the TSS, 

conformant with NTCIP 1201, and time is referenced to actual local time 

within the device. 

clockNo(2) - A real time clock is not provided within the TSS and 

time is expressed in the number of seconds since most recent TSS 

initialization. 

1.3.6.1.4.1.1206.4.2.4.1.6" 


5.2.7 Sensor Technology 

sensorTechnology OBJECT-TYPE 


other (1), 

inductiveLoop (2), 

machineVision (3) } 



DESCRIPTION 

" Indicates the sensor technology used by this TSS. 

other(1) - Any TSS that is not currently covered by this 

standard. (e.g., microwave detectors) 

inductive loop (2) - A physical detector of coiled wire that is 

embedded in the driving surface that senses changes in magnetic 

field as vehicles pass over. 

machine vision (3) - A non intrusive detection methodology 

where in a video image of the driving surface is processed to 

determine the passage of a vehicle. 

1.3.6.1.4.1.1206.4.2.4.1.7" 


5.2.8 Maximum Sample Data Entries 

maxSampleDataEntries OBJECT-TYPE 




DESCRIPTION 



Page 80 

" Indicates the maximum number of historical data entries per zone 

supported by the TSS. 

1.3.6.1.4.1.1206.4.2.4.1.8" 


5.2.9 Maximum Number of Characters 

maxNumberOfCharacters OBJECT-TYPE 




DESCRIPTION 

" The maximum number of characters per identifier label that the 

TSS supports. 

1.3.6.1.4.1.1206.4.2.4.1.9" 


5.2.10 Functional Capabilities 

functionalCapabilities OBJECT-TYPE 




DESCRIPTION 

" A bit-mapped value as defined below for identifying the 

functional capabilities of the TSS. 

 

bit 0 0=NOT SUPPORTED, 1=SUPPORTED Sampling Features 

bit 1 0=NOT SUPPORTED, 1=SUPPORTED Timing Features 

bit 2 0=NOT SUPPORTED, 1=SUPPORTED Speed Features 

bits 3..7 

Reserved (bit 7=MSB) 

1.3.6.1.4.1.1206.4.2.4.1.10" 


5.2.11 External Arming Inputs 

externalArmingInputs OBJECT-TYPE 




DESCRIPTION 

" This allows other devices to modify the states of the Arming 

Input Bits used by the TSS. There are separate clears and sets so that 

multiple TSSs could maintain the states of individual Arming Input Bits. It is 

envisioned that the first 24 bits would correspond to the Greens, Yellows, and 

Reds of phases 1 through 8 from the traffic signal controller. The last 8 bits 

would be used for other phases, overlaps, or special functions. If the Arming 

Pin inputs are DC then a low input is an ON and a high input is an OFF. If the 

Arming Pin inputs are AC then a low input is an OFF and a high input is an ON. 

 

byte 1 Bit 0 = Clear Arming Input bit 1, 

Bit 1 = Clear Arming Input bit 2, 













Page 81 






















byte 5 Bit 0 = Set Arming Input bit 1, 

Bit 1 = Set Arming Input bit 2, 































1.3.6.1.4.1.1206.4.2.4.1.11" 


5.2.12 Output Conditioning Table 

-- The outputConditioningTable replaces the loopOutputConditioningTable that 

-- is used in the TSS 1209 version v01 standard. 



Page 82 

outputConditioningTable OBJECT-TYPE 

SYNTAX SEQUENCE OF OutputConditioningEntry 



DESCRIPTION 

" Each table row contains objects for configuring detector sensor 

zone outputs. The number of rows in this table is equal to maxSensorZones. 

Table rows are set by the manufacturer, and row creation/deletion is not 

supported. 

static 


Page 83 

5.2.12.2 Zone Maximum Presence Time 

sensorZoneMaxPresenceTime OBJECT-TYPE 




DESCRIPTION 

" This object sets the maximum time that the zone holds presence 

before retuning. Values of 1 to 65534 seconds are available. A value of 0 

disables this timer and prevents a sensor zone occupancy from being tuned out 

at the end of a specific time. A value of 65,535 represents invalid data. 

second 

1.3.6.1.4.1.1206.4.2.4.1.12.1.2" 

::= { outputConditioningEntry 2 } 

5.2.12.3 Zone Output Delay Time 

sensorZoneOutputDelayTime OBJECT-TYPE 




DESCRIPTION 

" The output for the zone is delayed from start of sensor zone 

occupancy by the time specified (tenths of a second: 00.0 to 6553.5 sec). For 

the output to actually switch, the sensor zone occupancy is required to be 

continuous and still be present at the end of the delay time. 

tenths of a second 

1.3.6.1.4.1.1206.4.2.4.1.12.1.3" 

REFERENCE 

"NEMA TS2 Clause 3.5.5.5.4.c and 6.5.2.24.1" 


5.2.12.4 Zone Output Delay Mode Parameter 

sensorZoneOutputDelayMode OBJECT-TYPE 


delayEnablesHaveNoEffect (1), 

delayEnablesORedActive (2), 

delayEnablesORedNotActive (3), 

delayEnablesANDedActive (4), 

delayEnablesANDedNotActive (5) } 



DESCRIPTION 

" This parameter determines if and how the delay enables are used 

to modify the operation of the delay feature. 

delayEnablesHaveNoEffect(1) – The delay enables have no effect on the 

delay feature of the zone. 

delayEnablesORedActive(2) - If any of the delay enables are active the 

delay feature is active, else the delay feature is not active. 

delayEnablesORedNotActive(3) - If any of the delay enables are active 

the delay feature is not active, else the delay feature is inactive. 

delayEnablesANDedActive(4) - If all of the delay enables are active the 

delay feature is active, else the delay feature is not active. 

delayEnablesANDedNotActive(5) - If all of the delay enables are active 

the delay feature is not active, else the delay feature is active. 

1.3.6.1.4.1.1206.4.2.4.1.12.1.4" 




Page 84 

5.2.12.5 Zone Output Delay Enables 

sensorZoneOutputDelayEnables OBJECT-TYPE 




DESCRIPTION 

" This bit-mapped parameter identifies which Arming Pins, Arming 

Input Bits, and which state for each are to be used as enables for the delay 

feature. If the Arming Pin inputs are DC then a low input is an ON and a high 

input is an OFF. If the Arming Pin inputs are AC then a low input is an OFF 

and a high input is an ON. 

 

byte 1 

byte 2 

byte 3 

byte 4 

byte 5 

byte 6 

Bit 0 = Arming Pin 1 OFF, 
















Bit 0 = Arming Pin 1 ON, 
















Bit 0 = Arming Input bit 1 OFF, 


















Page 85 


byte 7 Bit 0 = Arming Input bit 17 OFF, 








byte 8 Bit 0 = Arming Input bit 25 OFF, 








byte 9 Bit 0 = Arming Input bit 1 ON, 

Bit 1 = Arming Input bit 2 ON, 































1.3.6.1.4.1.1206.4.2.4.1.12.1.5" 


5.2.12.6 Zone Output Extend Time 

sensorZoneOutputExtendTime OBJECT-TYPE 




DESCRIPTION 



Page 86 

" The output for the zone is extended, after the end of the period 

in which the sensor zone is occupied, by the amount of time specified (tenths 

of a second: 00.0 to 6553.5 sec). 


1.3.6.1.4.1.1206.4.2.4.1.12.1.6" 

REFERENCE 

"NEMA TS2 Clause 3.5.5.5.4.d and 6.5.2.24.2" 


5.2.12.7 Zone Output Extend Mode 

sensorZoneOutputExtendMode OBJECT-TYPE 


extendEnablesHaveNoEffect (1), 

extendEnablesORedActive (2), 

extendEnablesORedNotActive (3), 

extendEnablesANDedActive (4), 

extendEnablesANDedNotActive (5) } 



DESCRIPTION 

" This parameter determines if and how the extend enables will be 

used to modify the operation of the extend feature. 

extendEnablesHaveNoEffect(1) - The extend enables have no effect on the 

extend feature of the zone. 

extendEnablesORedActive(2) - If any of the extend enables are active the 

extend feature is active, else the extend feature is not active. 

extendEnablesORedNotActive(3) - If any of the extend enables are active 

the extend feature is not active, else the extend feature is active. 

extendEnablesANDedActive(4) - If all the extend enables are active the 

extend feature is active, else the extend feature is not active. 

extendEnablesANDedNotActive(5) - If all of the extend enables are active 

the extend feature is not active, else the extend feature is active. 

1.3.6.1.4.1.1206.4.2.4.1.12.1.7" 


5.2.12.8 Zone Output Extend Enables 

sensorZoneOutputExtendEnables OBJECT-TYPE 




DESCRIPTION 

" This bit-mapped parameter identifies which Arming Pins, Arming 

Input Bits, and which state for each are to be used as enables for the extend 

feature. If the Arming Pin inputs are DC then a low input is an ON and a high 

input is an OFF. If the Arming Pin inputs are AC then a low input is an OFF 

and a high input is an ON. 

 

byte 1 

byte 2 















Page 87 

byte 3 

Byte 4 

byte 5 

byte 6 

byte 7 

byte 8 

byte 9 































































Page 88 


























1.3.6.1.4.1.1206.4.2.4.1.12.1.8" 


5.2.12.9 Zone Output Sequenced 

sensorZoneOutputSequenced OBJECT-TYPE 




DESCRIPTION 

" This parameter identifies a zone that is required to have a 

detection before the zone associated with this output has a detection for this 

output to become active. This parameter can be used to create directional 

detection. If the zone associated with this output has a detection before the 

zone identified in this parameter, this output cannot be activated and the 

detection ceases before it can start watching the zone identified in this 

parameter. If the zone identified in this parameter has a detection and 

remains in detection, every time the zone associated with the output has a 

detection, its output is activated. The intent is that the two zones are in 

close enough proximity that a vehicle is able to be detected by both zones and 

that the last zone to detect the vehicle is the one that activates its output. 

1.3.6.1.4.1.1206.4.2.4.1.12.1.9" 


5.2.13 Pending Configuration File Name 

pendingConfigurationFileName OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE(8..32)) 



DESCRIPTION 

" This identifies the name of the pending configuration file that 

is used by the TSS upon issuing the executePendingConfiguration command. 

1.3.6.1.4.1.1206.4.2.4.1.13" 

::= { tssSystemSetup 13} 




Page 89 

5.3 SENSOR CONTROL OBJECTS 

tssControl OBJECT IDENTIFIER ::= { tss 2 } 

--node for output control data elements 

--a sensor zone can be mapped to any available output 

--outputs identify discrete activity states sensed within a zone 

--output states should be refreshed upon change of state for each output 

5.3.1 Maximum Number of Outputs 

maxOutputNumber OBJECT-TYPE 




DESCRIPTION 

" Indicates the maximum number of outputs supported by this TSS. 

output 

1.3.6.1.4.1.1206.4.2.4.2.1" 

::= { tssControl 1 } 

5.3.2 Output Configuration Table 

outputConfigurationTable OBJECT-TYPE 

SYNTAX SEQUENCE OF OutputConfigurationEntry 



DESCRIPTION 

" Table containing configuration data elements for each TSS 

physical output. The number of rows in this table is equal to the 

maxOutputNumber data element. Table rows are set by the manufacturer, and row 

creation/deletion is not supported. 

static 

1.3.6.1.4.1.1206.4.2.4.2.2" 


outputConfigurationEntry OBJECT-TYPE 

SYNTAX OutputConfigurationEntry 



DESCRIPTION 

" Row containing output configuration data elements." 

INDEX { outputNumber } 

::= { outputConfigurationTable 1} 

OutputConfigurationEntry ::= SEQUENCE { 

outputNumber 

INTEGER, 

outputSensorZoneNumber INTEGER, 

outputFailsafeMode 

INTEGER, 

outputModeStatus 

BITMAP8, 

outputLabel OCTET STRING (SIZE (8..255)), 

outputArmingEnables 

BITMAP96, 

outputArmingMode 

INTEGER 

} 

5.3.2.1 Output Number 

outputNumber OBJECT-TYPE 




DESCRIPTION 



Page 90 

" The numerical label or number assigned to a physical output. 

Output number is also the row to which the outputConfigurationTable is 

referenced. 

1.3.6.1.4.1.1206.4.2.4.2.2.1.1" 

::= { outputConfigurationEntry 1 } 

5.3.2.2 Output Sensor Zone Number 

outputSensorZoneNumber OBJECT-TYPE 




DESCRIPTION 

"The numerical label or number representing the sensor zone number 

that is associated with this output. A value of zero (0) indicated that no 

sensor zone number is associated with this output. When read, this data 

element returns the last value written. 

1.3.6.1.4.1.1206.4.2.4.2.2.1.2" 

::= { outputConfigurationEntry 2} 

5.3.2.3 Output Failsafe Mode 

outputFailsafeMode OBJECT-TYPE 


failsafeModeOn (1), 

failsafeModeOff (2), 

overrideCommandOn (3), 

overrideCommandOff (4), 

normal (5) } 



DESCRIPTION 

" Data element that allows configuration of outputs for failure 

override modes, as follows: 

failsafeModeOn(1) - The output is set to the ON state whenever there is 

a failure that affects the proper performance of this output; 

failsafeModeOff(2) - The output is set to the OFF state whenever there 

is a failure that affects the proper performance of this output; 

overrideCommandOn(3) - The output is set to the ON state, overriding the 

normal operational state of the output; 

overrideCommandOff(4) - The output is set to the OFF state, overriding 

the normal operational state of the output; 

normal(5) - The output is returned to its normal operational state. 

When read, this data element returns the last value written except for 

the value of 5. After a value of 5 is written, the value prior to the 

normal command is returned. 

1.3.6.1.4.1.1206.4.2.4.2.2.1.3" 


5.3.2.4 Output Mode Status 

outputModeStatus OBJECT-TYPE 




DESCRIPTION 

" A bit-mapped value as defined below for reading the status of 

failure override modes, as follows: 

 

bit 7 0 = OFF, 1 = ON For Failsafe Mode Status ON indicates the 

Failsafe Mode is ON, meaning that the 




Page 91 

output assumes an ON state whenever there 

is a failure that in any way affects the 

proper performance of this output and 

Failsafe Mode Status OFF indicates the 

status of the Failsafe Mode is OFF, 

meaning that the output assumes an OFF 

state whenever there is a failure that in 

any way affects the proper performance of 

this output (MSB); 

bit 6 0 = OFF, 1 = ON For Override Command Status ON indicates 

the presence of an Override to the normal 

operational state of the output to ON and 

Override Command Status Off indicates the 

presence of an Override to the normal 

operational state of the output to OFF; 

bit 5..0 

Reserved (bit 0 = LSB). 

1.3.6.1.4.1.1206.4.2.4.2.2.1.4" 


5.3.2.5 Output Label 

outputLabel OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE (8..255)) 



DESCRIPTION 

" Text string to describe the TSS output. A maximum string length 

of less than 255 may be supported. 

1.3.6.1.4.1.1206.4.2.4.2.2.1.5" 


5.3.2.6 Output Arming Enables 

outputArmingEnables OBJECT-TYPE 




DESCRIPTION 

" Consists of up to 16 physical Arming Pins to the TSS and up to 

32 bits of external arming bits which can be controlled through this protocol. 

The Arming Pins have historically been connected to the phase greens but can 

be used for any purpose. It is envisioned that the phase green information 

could be sent through Arming Input Bits using the protocol and eliminate the 

need for additional wiring. If the Arming Pin inputs are DC then a low input 

is an ON and a high input is an OFF. If the Arming Pin inputs are AC then a 

low input is an OFF and a high input is an ON. 

 

byte 1 

byte 2 

















Page 92 

byte 3 

byte 4 

byte 5 

byte 6 

byte 7 

byte 8 

byte 9 

byte 10 
































































Page 93 

byte 11 

byte 12 






















Bit 7 = Arming Input bit 32 ON. 

1.3.6.1.4.1.1206.4.2.4.2.2.1.6" 


5.3.2.7 Output Arming Mode 

outputArmingMode OBJECT-TYPE 


armingEnablesHaveNoEffect (1), 

normOffArmingEnablesORedZone (2), 

normOnArmingEnablesORedZone (3), 

normZoneArmingEnablesORedOff (4), 

normZoneArmingEnablesORedOn (5), 

normOffArmingEnablesANDedZone (6), 

normOnArmingEnablesANDedZone (7), 

normZoneArmingEnablesANDedOff (8), 

normZoneArmingEnablesANDedOn (9)} 



DESCRIPTION 

" This parameter determines if and how the Arming Enables are used 

to modify the operation of this output. 

armingEnablesHaveNoEffect(1) - The Arming Enables have no effect on the 

output of the zone. 

normOffArmingEnablesORedZone(2) - The zone output is OFF when none of 

the Arming Enables are active, and the actual zone state when any of 

the Arming Enables are active. 

normOnArmingEnablesORedZone(3) - The zone output is ON when none of 

the Arming Enables are active, and the actual zone state when any of 


normZoneArmingEnablesORedOff(4) - The zone output is the actual zone 

state when none of the Arming Enables are active, and OFF when any of 


normZoneArmingEnablesORedOn(5) - The zone output is the actual zone 

state when none of the Arming Enables are active, and ON when any of 


normOffArmingEnablesANDedZone(6) - The zone output is OFF when any of 

the Arming Enables are not active, and the actual zone state when all 

of the Arming Enables are active. 



Page 94 

normOnArmingEnablesANDedZone(7) - The zone output is ON when any of 

the Arming Enables are not active, and the actual zone state when all 

of the Arming Enables or active. 

normZoneArmingEnablesANDedOff(8) - The zone output is the actual zone 

state when any of the Arming Enables are not active, and OFF when all of 


normZoneArmingEnablesANDedOn(9) - The zone output is the actual zone 

state when any of the Arming Enables are not active, and ON when all of 


1.3.6.1.4.1.1206.4.2.4.2.2.1.7" 


5.3.3 Maximum Number of Output Groups 

maxOutputGroups OBJECT-TYPE 




DESCRIPTION 

" Indicates the maximum number of output groups supported by this 

TSS. 

output 

1.3.6.1.4.1.1206.4.2.4.2.3" 


5.3.4 Output Group Table 

outputGroupTable OBJECT-TYPE 

SYNTAX SEQUENCE OF OutputGroupEntry 



DESCRIPTION 

" A table containing input and output states for groups of eight 

outputs. Each output group represents a multiple of eight (8) sequentially 

numbered outputs. Output Group 1 consists of Outputs 1 to 8, Output Group 2 

consists of Outputs 9 to 16, etc. The number of rows in this table is equal to 

the maxOutputGroups data element. Table rows are set by the manufacturer, and 

row creation/deletion is not supported. 

static 

1.3.6.1.4.1.1206.4.2.4.2.4" 


outputGroupEntry OBJECT-TYPE 

SYNTAX OutputGroupEntry 



DESCRIPTION 

" Table for output states, in groups of eight outputs. Each output 

group represents a multiple of eight (8) sequentially numbered outputs. 

Example: Output Group 1 consists of Outputs 1 to 8, Output Group 2 consists of 

Outputs 9 to 16, etc." 

INDEX { outputGroupNumber } 

::= { outputGroupTable 1 } 

OutputGroupEntry ::= SEQUENCE { 

outputGroupNumber 

outputGroupOutputState 

} 

INTEGER, 

BITMAP8 




Page 95 

5.3.4.1 Output Group Number 

outputGroupNumber OBJECT-TYPE 




DESCRIPTION 

" Number of the output group, in groups of eight outputs. Each 

output group represents a multiple of eight (8) sequentially numbered outputs. 

Output Group 1 consists of Outputs 1 to 8, Output Group 2 consists of Outputs 

9 to 16, etc. 

output 

1.3.6.1.4.1.1206.4.2.4.2.4.1.1" 

::= { outputGroupEntry 1 } 

5.3.4.2 Output Group Output State 

outputGroupOutputState OBJECT-TYPE 




DESCRIPTION 

" Each bit represents the output state for each output within each 

output group. Each output group represents a multiple of eight (8) 

sequentially numbered outputs. Example: Output Group 1 consists of Outputs 1 

to 8, Output Group 2 consists of Outputs 9 to 16, etc. Bit 0 represents output 

1, bit 1 represents output 2, etc., as follows: 

 

bit 7 0 = OFF, 1 = ON For output 8 within the group (MSB), 

bit 6 0 = OFF, 1 = ON For output 7 within the group, 






bit 0 0 = OFF, 1 = ON For output 1 within the group (LSB). 

1.3.6.1.4.1.1206.4.2.4.2.4.1.2" 

::= { outputGroupEntry 2 } 

5.4 TSS DATA COLLECTION OBJECTS 

tssDataCollection OBJECT IDENTIFIER ::= { tss 3 } 

-- node for data collection elements 

5.4.1 Data Collection Table 

-- This object has been deprecated. See Annex D for more information. 

dataCollectionTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DataCollectionEntry 


STATUS deprecated 

DESCRIPTION 

" Table containing the most recently completed sample period data. 

The number of rows in this table is equal to the maxSensorZones data element. 

Table rows are set by the manufacturer, and row creation/deletion is not 

supported. 

If this object is supported, it reports the same data that is returned using 

the new object sampleDataTable with a sampleZoneClass of one and a 

sampleEntryNum of two. 

static 

1.3.6.1.4.1.1206.4.2.4.3.1" 



Page 96 

::= { tssDataCollection 1 } 

dataCollectionEntry OBJECT-TYPE 

SYNTAX DataCollectionEntry 



DESCRIPTION 

" Table for data collection parameters." 


::= { dataCollectionTable 1 } 

DataCollectionEntry ::= SEQUENCE { 

endTime 

Counter, 

volumeData INTEGER, 

percentOccupancy INTEGER, 

speedData 

INTEGER, 

zoneStatus INTEGER 

} 

5.4.1.1 End Time 


endTime OBJECT-TYPE 

SYNTAX Counter 



DESCRIPTION 

" Indicates the time at which the data collection period ended for 

the data contained in this row, the most recently completed sample period. If 

the clockAvailable data element indicates the presence of a clock, this time 

shall be expressed in local time as expressed in the controllerLocalTime data 

element (see NTCIP 1201 v03); otherwise, this time shall be expressed in the 

number of seconds since the most recent TSS initialization. 

If this object is supported, it must report the same data that will be 

returned using the new object, sampleDataTable.sampleEndTime, with a 

sampleZoneClass of one and a sampleEntryNum of two. 

second 

1.3.6.1.4.1.1206.4.2.4.3.1.1.1" 

::= { dataCollectionEntry 1 } 

5.4.1.2 Volume Data 

--This object has been deprecated. See Annex D for more information. 

volumeData OBJECT-TYPE 




DESCRIPTION 

" Counts per sample period, for the most recently completed sample 

period. Counts are expressed as an integer value in the volumeData data 

element. The value of 65535 shall be returned to represent a missing value. A 

missing value is reported when the zoneStatus is anything other than OK for 

the entire sampling period. 

If this object is supported, it is required to report the same data that is 

returned using the new object, sampleDataTable.sampleVolumeData, with a 


count 

1.3.6.1.4.1.1206.4.2.4.3.1.1.2" 




Page 97 


5.4.1.3 Percent Occupancy 


percentOccupancy OBJECT-TYPE 




DESCRIPTION 

" Percent occupancy over the sample period for the most recently 

completed sample period. Occupancy is expressed in tenths of a percent, from 0 

to 100.0 percent, in the percentOccupancy data element. The value of 65535 

shall be returned to represent an invalid or missing value. A missing value is 

reported when the zoneStatus is anything other than OK for the entire sampling 

period. Values 1001 through 65534 are reserved for future use. 

If this object is supported, it must report the same data that will be 

returned using the new object, sampleDataTable.samplePercentOccupancy, with a 


percent 

1.3.6.1.4.1.1206.4.2.4.3.1.1.3" 


5.4.1.4 Speed Data 


speedData OBJECT-TYPE 




DESCRIPTION 

" Arithmetic mean of speeds collected over the sample period with 

units of 1/10ths of km/h, for the most recently completed sample period. For a 

volume of zero during the sample period, the value of 65535 shall be returned 

to represent an invalid or missing value. A missing value is reported when the 

zoneStatus returned indicates no other status values apply for the entire 

sampling period. Values 2551 through 65534 are reserved for future use. 


returned using the new object, sampleDataTable.sampleSpeedData, with a 


tenths of km/h 

1.3.6.1.4.1.1206.4.2.4.3.1.1.4" 

-- conversion to English units must be done within the application 


5.4.1.5 Zone Status 


zoneStatus OBJECT-TYPE 


other (1), 

oK (2), 






disabled (8), 




Page 98 

sensorFailure (10) } 



DESCRIPTION 


Value 

Meaning 

Other - Indicates an error has occurred within the TSS for which 


oK - Indicates no other status values apply, 

initializing - Indicates an initialization or diagnostics procedure is 

in-progress, 

noActivity - Indicates no activity condition, 

maxPresence - Indicates max presence condition, 

configurationError - Indicates an error within the TSS configuration 

setup, 

erraticCounts - Indicates erratic counts, 

disabled - Indicates that the zone is disabled. 

overrideActive - Indicates an override is active. 

sensorFailure - Indicates a sensing element failure. 





returned using the new object, sampleDataTable.sampleZoneStatus, with a 


1.3.6.1.4.1.1206.4.2.4.3.1.1.5" 


5.4.2 Data Buffer Table 


dataBufferTable OBJECT-TYPE 

SYNTAX SEQUENCE OF DataBufferEntry 



DESCRIPTION 

" Table containing the second most recently completed previous 

sample period data, which value is specified by the value of the 

sensorZoneSamplePeriod data element. The previous period data overwrites the 

data for the sample period data immediately preceding the previous sample 

period. The number of rows in this table is equal to the maxSensorZones data 

element. Table rows are set by the manufacturer, and row creation/deletion is 

not supported. 


returned using the new object sampleDataTable with a sampleZoneClass of one 

and a sampleEntryNum of three. 

static 

1.3.6.1.4.1.1206.4.2.4.3.2" 


dataBufferEntry OBJECT-TYPE 

SYNTAX DataBufferEntry 



DESCRIPTION 

" Table containing the data collection parameters for the second 

most recently completed previous sample period." 




Page 99 


::= { dataBufferTable 1 } 

DataBufferEntry ::= SEQUENCE { 

endTimeBuffer 

Counter, 

volumeDataBuffer INTEGER, 

percentOccupancyBuffer INTEGER, 

speedDataBuffer 

INTEGER, 

zoneStatusBuffer INTEGER 

} 

5.4.2.1 End Time Buffer 


endTimeBuffer OBJECT-TYPE 




DESCRIPTION 


the data contained in this row, the second most recently completed previous 

sample period. If the clockAvailable data element indicates the presence of a 

clock, this time shall be expressed in local time as expressed in the 

controllerLocalTime data element (see NTCIP 1201 v03); otherwise, this time 

shall be expressed in the number of seconds since the most recent TSS 

initialization. 


returned using the new object, sampleDataEntry.sampleEndTime, with a 

sampleZoneClass of one and a sampleEntryNum of three. 

second 

1.3.6.1.4.1.1206.4.2.4.3.2.1.1" 

::= { dataBufferEntry 1 } 

5.4.2.2 Volume Data Buffer 


volumeDataBuffer OBJECT-TYPE 




DESCRIPTION 

" Counts per sample period, for the second most recently completed 

previous sample period. Counts are expressed as an integer value in the 

volumeData data element. The value of 65535 shall be returned to represent a 

missing value. A missing value is reported when the zoneStatusBuffer returned 

indicates no other status values apply for the entire sampling period. 


returned using the new object, sampleDataEntry.sampleVolumeData, with a 


count 

1.3.6.1.4.1.1206.4.2.4.3.2.1.2" 


5.4.2.3 Percent Occupancy Buffer 


percentOccupancyBuffer OBJECT-TYPE 




Page 100 



DESCRIPTION 

" Percent occupancy over the sample period for the second most 

recently completed previous sample period. Occupancy is expressed in tenths of 

a percent, from 0 to 100.0 percent, in the percentOccupancy data element. The 

value of 65535 shall be returned to represent an invalid or missing value. A 

missing value is reported when the zoneStatusBuffer is anything other than OK 

for the entire sampling period. Values 1001 through 65534 are reserved for 

future use. 


returned using the new object, sampleDataEntry.samplePercentOccupancy, with a 


percent 

1.3.6.1.4.1.1206.4.2.4.3.2.1.3" 


5.4.2.4 Speed Data Buffer 


speedDataBuffer OBJECT-TYPE 




DESCRIPTION 

" Arithmetic mean of speeds collected over the sample period, 

with units of 1/10ths of km/hr, for the second most recently completed 

previous sample period. For a volume of zero during the sample period, the 

value of 65535 shall be returned to represent an invalid or missing value. A 

missing value is reported when the zoneStatusBuffer is anything other than OK 

for the entire sampling period. Values 2551 through 65534 are reserved for 

future use. 


returned using the new object, sampleDataEntry.sampleSpeedData, with a 


tenths of km/hr 

1.3.6.1.4.1.1206.4.2.4.3.2.1.4" 

-- conversions to English units from SI are required to be done within the 

applications 


5.4.2.5 Zone Status Buffer 


zoneStatusBuffer OBJECT-TYPE 


other (1), 

oK (2), 






disabled (8), 


sensorFailure (10) 

} 






Page 101 

DESCRIPTION "Detailed status returned as result of diagnostics, for the 

previous sample period, as follows: 

Value Meaning 

Other - Indicates an error has occurred within the TSS for which 


oK - Indicates no other status values apply, 

initializing - Indicates an initialization or diagnostics procedure is 

in-progress, 

noActivity - Indicates no activity condition, 

maxPresence - Indicates max presence condition, 

configurationError - Indicates an error within the TSS configuration 

setup, 

erraticCounts - Indicates erratic counts, 

disabled - Indicates that the zone is disabled, 

overrideActive - Indicates an override is active, 

sensorFailure - Indicates a sensing element failure. 





returned using the new object, sampleDataEntry.sampleZoneStatus, with a 


1.3.6.1.4.1.1206.4.2.4.3.2.1.5" 


5.4.3 Zone Sequence Table 

zoneSequenceTable OBJECT-TYPE 

SYNTAX SEQUENCE OF ZoneSequenceTableEntry 



DESCRIPTION 

" Table containing entries for the number of historical data 

entries and the number of classes available for retrieval for each zone. The 

maxSensorZones defines the number of entries in this table. For each zone, 

retrieve the numSampleDataEntries available and the sensorZoneClass for those 

historical data entries, then retrieve the appropriate data samples from the 

sampleDataTable. 

static 

1.3.6.1.4.1.1206.4.2.4.3.3" 


zoneSequenceTableEntry OBJECT-TYPE 

SYNTAX ZoneSequenceTableEntry 



DESCRIPTION 

" Table containing the number of historical data entries and the 

number of classes within each historical data entry for each zone. The 

maxSensorZones table defines the number of entries in this table." 


::= { zoneSequenceTable 1 } 

ZoneSequenceTableEntry::= SEQUENCE { 

numSampleDataEntries INTEGER, 

numSensorZoneClass INTEGER 

} 



Page 102 

5.4.3.1 Number of Sample Data Entries 

numSampleDataEntries OBJECT-TYPE 




DESCRIPTION 

" The number of historical data entries in the sampleDataTable for 

a particular zone. 

count 

1.3.6.1.4.1.1206.4.2.4.3.3.1.1" 

::= { zoneSequenceTableEntry 1 } 

5.4.3.2 Number of Sensor Zone Class 

numSensorZoneClass OBJECT-TYPE 




DESCRIPTION 

" This is the number of classes currently supported for each 

historical data entry for a particular zone. 

1.3.6.1.4.1.1206.4.2.4.3.3.1.2" 

::= { zoneSequenceTableEntry 2 } 

5.4.4 Sample Data Table 

sampleDataTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SampleDataEntry 



DESCRIPTION 

" Table containing the historical sample period data. The number 

of rows in this table is equal to the maxSensorZones data element multiplied 

by the maxSampleDataEntries data element. Table rows are set by the 

manufacturer, and row creation/deletion is not supported. 

To retrieve all historical data entries for a zone, the last (oldest) entry 

should be retrieved by using numSampleDataEntries and retrieving class one (1) 

through numSensorZoneClass first. Class 1 is an aggregation of the data from 

all of the other classes (if any exist). All of the class data for a 

particular numSampleDataEntries has the same sequenceNumber. Once these 

entries are retrieved, the other entries sequence numbers denote the correct 

order of the samples. Sequence number is used rather than end date as the 

system clock may have been reset between data samples. 

static 

1.3.6.1.4.1.1206.4.2.4.3.4" 


sampleDataEntry OBJECT-TYPE 

SYNTAX SampleDataEntry 



DESCRIPTION 

" Table for data collection parameters." 

INDEX { sensorZoneNumber, sampleEntryNum, sampleZoneClass } 

::= { sampleDataTable 1 } 

SampleDataEntry ::= SEQUENCE { 




Page 103 

sampleEntryNum 

INTEGER, 

sampleZoneClass 

INTEGER, 

sampleEndTime 

Counter, 

sampleVolumeData INTEGER, 

samplePercentOccupancy INTEGER, 

sampleSpeedData 

INTEGER, 

sampleZoneStatus INTEGER, 

sampleSequenceNumber INTEGER 

} 

5.4.4.1 Sample Entry Number 

sampleEntryNum OBJECT-TYPE 




DESCRIPTION 

" This identifies which historical sampling period that data is 

being requested from. 1 being the sampling period currently in-progress. 2 

being the most recently completed sampling period. 

count 

1.3.6.1.4.1.1206.4.2.4.3.4.1.1" 

::= { sampleDataEntry 1 } 

5.4.4.2 Sample Zone Class 

sampleZoneClass OBJECT-TYPE 




DESCRIPTION 

" This identifies the class of the sensor zone from which 

historical sampling period data is being requested. Class 1 retrieves an 

aggregate of the data from all classes within the requested historical data 

entry. 

1.3.6.1.4.1.1206.4.2.4.3.4.1.2" 


5.4.4.3 Sample End Time 

sampleEndTime OBJECT-TYPE 




DESCRIPTION 


the data contained in this row. If the clockAvailable data element indicates 

the presence of a clock, this time shall be expressed in local time as 

expressed in the controllerLocalTime data element (see NTCIP 1201 v03); 

otherwise, this time shall be expressed in the number of seconds since the 

most recent TSS initialization. 

seconds 

1.3.6.1.4.1.1206.4.2.4.3.4.1.3" 


5.4.4.4 Sample Volume Data 

sampleVolumeData OBJECT-TYPE 




DESCRIPTION 



Page 104 

" Counts per sample period. Counts are expressed as an integer 

value in the sampleVolumeData data element. For a virtual zone (one created 

using any AND Boolean functions), volume is the number of times that the 

output for the zone was activated. For a virtual zone (one created using only 

OR Boolean functions), volume is the additive total of the volumes of all of 

the zones that make up the virtual zone. The value of 65535 shall be returned 

to represent a missing value. A missing value is reported when the zoneStatus 

is anything other than OK for the entire sampling period. 

count 

1.3.6.1.4.1.1206.4.2.4.3.4.1.4" 


5.4.4.5 Sample Percent Occupancy 

samplePercentOccupancy OBJECT-TYPE 




DESCRIPTION 

" Percent occupancy over the sample period. Occupancy is expressed 

in tenths of a percent, from 0 to 100.0 percent, in the samplePercentOccupancy 

data element. For a virtual zone (one created using AND and/or OR Boolean 

functions), the percent of time that the output for the zone was activated 

shall be returned. The value of 65535 shall be returned to represent an 

invalid or missing value. A missing value is reported when the zoneStatus is 

anything other than OK for the entire sampling period. Values 1001 through 

65534 are reserved for future use. 

percent 

1.3.6.1.4.1.1206.4.2.4.3.4.1.5" 


5.4.4.6 Sample Speed Data 

sampleSpeedData OBJECT-TYPE 




DESCRIPTION 

" Arithmetic mean of speeds collected over the sample period with 

units of 1/10ths of km/h. For a virtual zone (one created using AND and/or OR 

Boolean functions), the value of 65535 shall be returned as it is not straight 

forward to calculate speed from logically combined zones. For a volume of zero 

during the sample period, the value of 65535 shall be returned to represent an 

invalid or missing value. A missing value is reported when the zoneStatus 

returned indicates no other status values apply for the entire sampling 

period. Values 2551 through 65534 are reserved for future use. 

tenths of km/h 

1.3.6.1.4.1.1206.4.2.4.3.4.1.6" 

-- conversion to English units must be done within the application 


5.4.4.7 Sample Zone Status 

sampleZoneStatus OBJECT-TYPE 


other (1), 

oK (2), 








Page 105 


disabled (8), 


sensorFailure (10), 

inputDataIntegrity (11), 

poorContrast (12), 

detectionAutoSuspended (13), 

pairedZoneFault (14) } 



DESCRIPTION 


Value Meaning 

other(1) - Indicates an error has occurred within the TSS for which 


oK(2) - Indicates no other status values apply, 

initializing(3) - Indicates an initialization or diagnostics procedure 

is in-progress, 

noActivity(4) - Indicates no activity condition, 

maxPresence(5) - Indicates max presence condition, 

configurationError(6) - Indicates an error within the TSS 

configuration setup, 

erraticCounts(7 )- Indicates erratic counts, 

disabled(8) - Indicates that the zone is disabled, 

overrideActive(9) - Indicates an override is active, 

sensorFailure(10) - Indicates a sensing element failure, 

inputDataIntegrity(11) - indicates input values are not sufficient to 

determine detector data accurately (e.g., bad communications, invalid 

video for machine vision), 

poorContrast(12) - Indicates insufficient contrast error condition, 

detectionAutoSuspended(13) - Indicates that the detection zone was 

automatically disabled by the TSS (e.g., camera is on a PTZ and 

was moved), 

pairedZoneFault(14) - Indicates that there was no problem with this 

zone, but a zone that it is paired with had a fault. This may affect 

the accuracy of data reported by this zone. 




1.3.6.1.4.1.1206.4.2.4.3.4.1.7" 


5.4.4.8 Sample Sequence Number 

sampleSequenceNumber OBJECT-TYPE 




DESCRIPTION 

" The data samples sequence number, used to determine the 

appropriate order of samples for a particular zone. All data from the same 

sampling period have the same historical sequence number (all classes from the 

same period have the same sequence number). 

count 

1.3.6.1.4.1.1206.4.2.4.3.4.1.8" 




Page 106 

5.4.5 Zone Class Table 

zoneClassTable OBJECT-TYPE 

SYNTAX SEQUENCE OF ZoneClassTableEntry 



DESCRIPTION 

" This is a table that allows the TSS to return a class label for 

a particular class of a particular zone. These are most likely set by the 

manufacturer; however the manufacturer may allow the user to modify these 

through means outside of this protocol. 

static 

1.3.6.1.4.1.1206.4.2.4.3.5" 


zoneClassTableEntry OBJECT-TYPE 

SYNTAX ZoneClassTableEntry 



DESCRIPTION 

" Table containing entries for the class labels for each zone." 

INDEX { sensorZoneNumber, sampleZoneClass } 

::= { zoneClassTable 1 } 

ZoneClassTableEntry ::= SEQUENCE { 

zoneClassLabel OCTET STRING 

} 

5.4.5.1 Zone Class Label 

zoneClassLabel OBJECT-TYPE 




DESCRIPTION 

" The label assigned to a particular class number to aid in 

identifying the data contained within the class. 

1.3.6.1.4.1.1206.4.2.4.3.5.1.1" 

::= { zoneClassTableEntry 1 } 

5.5 INDUCTIVE LOOP DETECTOR OBJECTS 

tssInductiveLoop OBJECT IDENTIFIER ::= { tss 4 } 

-- This node contains the configuration objects specific to inductive loop 

-- detectors. 

-- These objects set up physical parameters on the detector that are 

-- controlled on a per output basis. 

-- These objects are only valid for the zones that map directly to an output 

-- on the detector. 

-- Zone 1 maps to output 1 and Zone 2 maps to output 2 on a two-channel 

-- sensor unit and Zone 3 maps to output 3, and Zone 4 maps to output 4 on a 

-- four-channel sensor unit. 

-- For inductive loop detectors, the term "channel" is often used to refer to 

-- an "output". 

5.5.1 Loop System Setup Table 

loopSensorSetupTable OBJECT-TYPE 

SYNTAX SEQUENCE OF LoopSensorSetupEntry 





Page 107 


DESCRIPTION 

" This table contains inductive loop detector sensor zone 

parameters. The number of rows in this table does not exceed maxSensorZones. 

This table contains the configuration objects specific to inductive loop 

detectors. These objects set up physical parameters on the detector that are 

controlled on a per output basis. A zone maps directly to an output on an 

inductive loop detector - Zone 1 maps to output 1, Zone 2 maps to output 2, 

and, on a four-channle sensor unit Zone 3 maps to output 3 and Zone 4 maps to 

output 4. Virtual zones may be supported once all physical outputs have had 

sensor zones mapped to them. Table rows are set by the manufacturer, and row 


static 

1.3.6.1.4.1.1206.4.2.4.4.1" 

::= { tssInductiveLoop 1 } 

loopSensorSetupEntry OBJECT-TYPE 

SYNTAX LoopSensorSetupEntry 



DESCRIPTION 

" Row in table that contains inductive loop detector sensor zone 

parameters. The number of rows in this table does not exceed maxSensorZones or 

maxOutputNumber, whichever is greater. Table rows are set by the manufacturer, 

and row creation/deletion is not supported." 


::= { loopSensorSetupTable 1 } 

LoopSensorSetupEntry ::= SEQUENCE { 

zoneSensitivityMode INTEGER, 

zoneSensitivity 

OCTET STRING, 

zoneFrequencyRange OCTET STRING, 

sensorZoneLoopLayout INTEGER 

} 

5.5.1.1 Zone Sensitivity Mode 

zoneSensitivityMode OBJECT-TYPE 


deltaL (1), 

deltaLOverSqrtL (2), 

deltaLOverL (3) } 



DESCRIPTION 

" Sensitivity mode in use (3=∆L/L, 2=∆L/√L, 1=∆L). This is a 

characteristic of the loop detector being used. 

1.3.6.1.4.1.1206.4.2.4.4.1.1.1" 

::= { loopSensorSetupEntry 1 } 

5.5.1.2 Zone Sensitivity 

zoneSensitivity OBJECT-TYPE 

SYNTAX OCTET STRING (SIZE(2)) 



DESCRIPTION 

" This bit-mapped object allows the setting and reading of the 

sensitivity for the zone as follows: 



Page 108 

 

bit 3,bit 2,bit1,bit 0 Meaning 

0000 Zone OFF (Disabled) (LSB) 

0001 Detect ∆L = 512 nanoHenries or ∆L/L = 0.64% 

0010 Detect ∆L = 256 nanoHhenries or ∆L/L = 0.32% 






or, if bit 15=1 Detect ∆L = 0 to 32,767 nanoHenries or ∆L/L = 0 to 

32.767% (MSB) 

These sensitivity definitions are equal with a loop inductance of 80 

microHenries. A detector need not support all of these settings. However, the 

sensitivities it does support are required to conform with these definitions, 

e.g. a sensitivity setting of 3 is always 128 nanoHenries or 0.16% with an 80 

microhenry loop. If bit 15=1, bit 0 – bit 14 contain the sensitivity in 

nanoHenries or one-thousands of a percent, e.g. 3650 is 3.650%. A value of 

65535 shall be returned to represent invalid data or not a physical zone. 

Values of 8 through 32767 are reserved. 

1.3.6.1.4.1.1206.4.2.4.4.1.1.2" 


5.5.1.3 Zone Frequency Range 

zoneFrequencyRange OBJECT-TYPE 




DESCRIPTION 

" Allows the setting and reading of the frequency range as 

follows: 

 

bit 2, bit 1, bit 0 

Meaning 

000 Frequency Range 0 (lowest frequency) (LSB) 

001 Frequency Range 1 

010 Frequency Range 2 

011 Frequency Range 3 (highest frequency for 4 freq. unit) 

(MSB) 

As the frequency number increases the operation frequency shall increase. The 

loop frequency at the lowest frequency setting shall be less than 88% of the 

loop frequency at the highest frequency setting. Bit 3 can be used to allow a 

unit to support 8 frequency ranges instead of the four. A value of 255 shall 

be returned to represent invalid data or not a physical zone. Values of 8 

through 254 are reserved. 

1.3.6.1.4.1.1206.4.2.4.4.1.1.3" 


5.5.1.4 Sensor Zone Loop Layout 

sensorZoneLoopLayout OBJECT-TYPE 


other (1), 

oneSixBySixLoopOneLane (2), 

twoSixBySixLoopsOneLane (3), 

threeSixBySixLoopsOneLane (4), 

fourSixBySixLoopsOneLane (5), 

oneLongLoopOneLane (6), 

oneSixBySixLoopMultipleLanes (7) } 




Page 109 



DESCRIPTION 

" The zone configuration provides for standardized sensor loop 

layouts typically used in roadway applications. 

other(1) - Used for special loop configurations and layouts. 

oneSixBySixLoopOneLane(2) - Used when there in one six-foot by sixfoot 

loop in one travel lane. 

twoSixBySixLoopsOneLane(3) - Used when there are two six-foot by sixfoot 

loops in one travel lane. 

threeSixBySixLoopsOneLane(4) - Used when there are three six-foot by 

six-foot loops in one travel lane. 

fourSixBySixLoopsOneLane(5) - Used when there are four six-foot by sixfoot 

loops in one travel lane. 

oneLongLoopOneLane(6) - Used when there is one loop in one travel 

lane that exceeds six-feet in length. 

oneSixBySixLoopMultipleLanes(7) - Used when there is one six-foot by 

six-foot loop in each of more than one travel lane. 

1.3.6.1.4.1.1206.4.2.4.4.1.1.4" 




loopOutputConditioningTable OBJECT-TYPE 

SYNTAX SEQUENCE OF LoopOutputConditioningEntry 



DESCRIPTION 

" Each table row contains objects for configuring inductive loop 

detector sensor zone outputs. The number of rows in this table does not exceed 

maxSensorZones. Table rows are set by the manufacturer, and row 


If this object is supported, it must use the same data that will be used by 

the new object outputConditioningTable. 

static 

1.3.6.1.4.1.1206.4.2.4.4.2" 


loopOutputConditioningEntry OBJECT-TYPE 

SYNTAX LoopOutputConditioningEntry 



DESCRIPTION 

" Each table row contains inductive loop detector sensor zone 

output conditioning parameters." 


::= { loopOutputConditioningTable 1 } 

LoopOutputConditioningEntry ::= SEQUENCE { 

zoneOutputMode 

INTEGER, 

zoneMaxPresenceTime INTEGER, 

zoneOutputDelayTime INTEGER, 

zoneOutputExtendTime INTEGER, 

zoneOutputExtendEnable OCTET STRING, 

zoneOutputDelayEnable OCTET STRING 

} 



Page 110 

5.5.2.1 Zone Output Mode 


zoneOutputMode OBJECT-TYPE 


other (1), 

pulse (2), 

presence (3) } 



DESCRIPTION 

" This object sets the length of the output during a detect 

condition. These detect outputs are described as follows: 

Other - an output mode other than that defined in this standard 

Pulse - a pulse of 125ms (±25ms) is output when a vehicle is 

detected. 

Presence - the output lasts the duration of a detect condition or 

until the detector tunes out the detect signal. 

A value of 255 shall be returned to represent invalid data. 

If this object is supported, it is required to use the same data that is used 

by the new object outputConditioningEntry.sensorZoneOutputMode. 

1.3.6.1.4.1.1206.4.2.4.4.2.1.1" 

::= { loopOutputConditioningEntry 1 } 

5.5.2.2 Zone Max Presence Feature Time 


zoneMaxPresenceTime OBJECT-TYPE 




DESCRIPTION 

" This object sets the maximum time that the zone holds presence 

before retuning. Values of 1 to 65534 seconds are available. A value of 0 

disables this timer and prevents a sensor zone occupancy from being tuned out 

at the end of a specific time. A value of 65,535 represents invalid data. 


by the new object outputConditioningEntry.sensorZoneMaxPresenceTime. 

second 

1.3.6.1.4.1.1206.4.2.4.4.2.1.2" 


5.5.2.3 Zone Output Delay Time 


zoneOutputDelayTime OBJECT-TYPE 




DESCRIPTION 

" The output for the zone is delayed from start of sensor zone 

occupancy by the time specified (tenths of a second: 00.0 to 6553.5 sec). For 

the output to actually switch, the sensor zone occupancy is required to be 

continuous and still be present at the end of the delay time. 


by the new object outputConditioningEntry.sensorZoneOutputDelayTime. 


1.3.6.1.4.1.1206.4.2.4.4.2.1.3" 




Page 111 

REFERENCE 

"NEMA TS2 Clause 3.5.5.5.4.c and 6.5.2.24.1" 


5.5.2.4 Zone Output Extend Time 


zoneOutputExtendTime OBJECT-TYPE 




DESCRIPTION 

" The output for the zone is extended, after the end of the period 

in which the sensor zone is occupied, by the amount of time specified (tenths 

of a second: 00.0 to 6553.5 sec). 


by the new object outputConditioningEntry.sensorZoneOutputExtendTime. 


1.3.6.1.4.1.1206.4.2.4.4.2.1.4" 

REFERENCE 

"NEMA TS2 Clause 3.5.5.5.4.d and 6.5.2.24.2" 


5.5.2.5 Zone Output Extend Enable 


zoneOutputExtendEnable OBJECT-TYPE 




DESCRIPTION 

" A bit-mapped value as defined below to enable and disable the 

extend time for the sensor zone output, as follows: 

 

bit 7 0 = NO, 1 = YES HIGH on output 1 Arming Pin to enable 

extend time for the zone (MSB), 


extend time for the zone, 





bit 3 0 = NO, 1 = YES LOW on output 1 Arming Pin to enable 

extend time for the zone (MSB), 






extend time for the zone (LSB). 

Extend time is always enabled for the zone if all bits are zero (0). 

If this object is supported, it must use the same data that will be used by 

the new objects outputConditioningEntry.sensorZoneOutputExtendMode and 

outputConditioningEntry.sensorZoneOutputExtendEnables to the extent possible. 

1.3.6.1.4.1.1206.4.2.4.4.2.1.5" 

REFERENCE 

"NEMA TS2 Clause 6.5.2.8.7, 6.5.2.24 and 6.5.2.25.6" 




Page 112 

5.5.2.6 Zone Output Delay Enabled 


zoneOutputDelayEnable OBJECT-TYPE 




DESCRIPTION 

" A bit-mapped value as defined below to enable and disable the 

delay time for the sensor zone output, as follows: 

 


delay time for the zone (MSB), 


delay time for the zone, 





bit 3 0 = NO, 1 = YES LOW on output 1 Arming Pin to enable delay 

time for the zone (MSB), 


time for the zone, 





Delay time is always enabled for the zone if all bits are zero (0). 


by the new objects outputConditioningEntry.sensorZoneOutputDelayMode and 

outputConditioningEntry.sensorZoneOutputDelayEnables to the extent possible. 

1.3.6.1.4.1.1206.4.2.4.4.2.1.6" 

REFERENCE 

"NEMA TS2 Clause 6.5.2.8.7, 6.5.2.24 and 6.5.2.25.6" 


5.5.3 Loop System Status Table 

loopSystemStatusTable OBJECT-TYPE 

SYNTAX SEQUENCE OF LoopSystemStatusEntry 



DESCRIPTION 

" This table contains inductive loop detector sensor zone status 

parameters. The number of rows in this table does not exceed maxSensorZones. 

This table contains instantaneous zone status objects specific to inductive 

loop detectors. The zoneDetectStatus object may be used by external systems 

for doing detailed traffic analysis. A zone maps directly to an output on an 

inductive loop detector - Zones 1 maps to output 1, Zone 2 maps to output 2, 

and, on a four output inductive loop detector, Zone 3 maps to output 3 and 

Zone 4 maps to output 4. Table rows are set by the manufacturer, and row 


static 

1.3.6.1.4.1.1206.4.2.4.4.3" 


loopSystemStatusEntry OBJECT-TYPE 

SYNTAX LoopSystemStatusEntry 






Page 113 

DESCRIPTION 

" Rows in this table contain inductive loop detector sensor zone 

status parameters. The number of rows in this table does not exceed 

maxSensorZones. Table rows are set by the manufacturer, and row 

creation/deletion is not supported." 


::= { loopSystemStatusTable 1 } 

LoopSystemStatusEntry ::= SEQUENCE { 

zoneInductance 

INTEGER, 

zoneFrequency 

INTEGER, 

zoneInductanceChange 

INTEGER, 

zoneFaultHistory 

BITMAP8, 

zoneFaultCount 

INTEGER, 

zonePercentInductanceChange INTEGER 

} 

5.5.3.1 Zone Inductance 

zoneInductance OBJECT-TYPE 




DESCRIPTION 

" The detector unit calculates the inductance of the loop attached 

to the zone. The resolution is in tenths of a microHenry. For example, 852.4 

microHenries is represented as 8524. Resolution does not imply accuracy, refer 

to manufacturers' data sheet. A value of 65535 shall be returned to represent 

invalid data or not a physical zone. 

tenths of a microHenry 

1.3.6.1.4.1.1206.4.2.4.4.3.1.1" 

::= { loopSystemStatusEntry 1 } 

5.5.3.2 Zone Frequency 

zoneFrequency OBJECT-TYPE 




DESCRIPTION 

" This is the frequency of the inductive loop attached to the 

zone. The frequency resolution is one-tenth hertz. For example, 53240 Hz is 

represented as 532400. Resolution does not imply accuracy, refer to 

manufacturers' data sheet. A value of 16777216 shall be returned to represent 

invalid data or not a physical zone. 

one-tenth Hertz 

1.3.6.1.4.1.1206.4.2.4.4.3.1.2" 


5.5.3.3 Zone Inductance Change 

zoneInductanceChange OBJECT-TYPE 




DESCRIPTION 

" The maximum inductance change seen since the last start of 

sensor zone occupancy is returned. The resolution is to one nanoHenry. 

Resolution does not imply accuracy. 

nanoHenry 



Page 114 

1.3.6.1.4.1.1206.4.2.4.4.3.1.3" 


5.5.3.4 Zone Fault History 

zoneFaultHistory OBJECT-TYPE 




DESCRIPTION 

" A bit-mapped value representing the history of faults in Zone 

since the last unit reset. 

 

bit 7 0 = NO, 1 = YES To indicate that a current fault exists 

on the loop connected to the zone (MSB); 

bit 6 0 = NO, 1 = YES To indicate that the loop connected to the 

zone is open or this was the last fault. 

(May be also be called a Maximum Presence 

fault by external units.); 

bit 5 0 = NO, 1 = YES To indicate that the loop connected to the 

zone is shorted or this was the last 

fault. (May also be called a No Activity 

fault by external units.); 

bit 4 0 = NO, 1 = YES To indicate that the loop inductance of 

the loop connected to the zone is 

currently ≥ ±25% of reference or this was 

the last fault. (May also be called a 

Erratic Count fault by external units.); 

bits 3..1 

Reserved; 

bit 0 0 = NO, 1 = YES To indicate that data for this value is 

invalid data or this is not a physical 

zone (LSB). 

1.3.6.1.4.1.1206.4.2.4.4.3.1.4" 


5.5.3.5 Zone Fault Count 

zoneFaultCount OBJECT-TYPE 




DESCRIPTION 

" Number of faults in the zone since the last unit reset. These 

faults include open circuit; short circuit and ±25% drift faults. The fault 

count may also include faults other than those defined in NTCIP 1209 v02. The 

count after 255 is 255. 

fault 

1.3.6.1.4.1.1206.4.2.4.4.3.1.5" 


5.5.3.6 Zone Percent Inductance Change 

zonePercentInductanceChange OBJECT-TYPE 




DESCRIPTION 

" The maximum inductance change seen since the last start of 

sensor zone occupancy is returned. The resolution is to one one-thousandth of 

a percent. Resolution does not imply accuracy. For example a change of 0.1 

percent would be represented as 100. 




Page 115 

one one-thousandth of a percent 

1.3.6.1.4.1.1206.4.2.4.4.3.1.3" 


5.6 MACHINE VISION OBJECTS 

tssMachineVision OBJECT IDENTIFIER ::={tss 5} 

-- This node contains the configuration objects specific to machine vision 

-- detectors 

5.6.1 Maximum Camera Count 

maxCameraCount OBJECT-TYPE 




DESCRIPTION 

" This is the maximum number of machine vision cameras supported 

by the system. 

1.3.6.1.4.1.1206.4.2.4.5.1" 

::= { tssMachineVision 1 } 

5.6.2 Machine Vision Camera Table 

machineVisionCameraTable OBJECT-TYPE 

SYNTAX SEQUENCE OF MachineVisionCameraEntry 



DESCRIPTION 

" This table contains camera parameters. The number of rows in 

this table does not exceed maxCameraCount. This table contains the 

configuration objects specific to machine vision cameras. Table rows are set 

by the manufacturer, and row creation/deletion is not supported. 

Static 

1.3.6.1.4.1.1206.4.2.4.5.2" 


machineVisionCameraEntry OBJECT-TYPE 

SYNTAX MachineVisionCameraEntry 



DESCRIPTION 

" Row in table that contains machine vision camera parameters. The 

number of rows in this table does not exceed maxCameraCount. Table rows are 

set by the manufacturer, and row creation/deletion is not supported. 

" 

INDEX { cameraNumber } 

::= { machineVisionCameraTable 1 } 

MachineVisionCameraEntry ::= SEQUENCE { 

cameraNumber 

INTEGER, 

cameraNameLabel 

OCTET STRING, 

imageReceptionDiagnostic INTEGER, 

cameraDetectionState 

INTEGER, 

zoneListForCamera 

BITMAP256, 

baselineImage 

INTEGER, 

snapshotImage 

INTEGER, 

cameraImageFormat 

BITMAP32 

} 



Page 116 

5.6.2.1 Camera Number 

cameraNumber OBJECT-TYPE 




DESCRIPTION 

" The numerical label or number of the machine vision camera. This 

number shall not exceed the maxCameraCount data element value. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.1" 

::= { machineVisionCameraEntry 1 } 

5.6.2.2 Camera Name Label 

cameraNameLabel OBJECT-TYPE 




DESCRIPTION 

" A text string used to describe the camera name or location. A 

camera name shall be a string length of less than 255 characters. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.2" 


5.6.2.3 Image Reception Diagnostic 

imageReceptionDiagnostic OBJECT-TYPE 




DESCRIPTION 

" Image Reception Diagnostics is a measure of the health of the 

image transition link from the camera to the machine vision processor. A value 

of 100 means that all of the frames are being received and a value of 0 means 

that frames are not being received. Values between 0 and 100 are manufacturerspecific. 

This is used to track and debug transmission errors from the camera 

to the machine vision processor. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.3" 


5.6.2.4 Camera Detection State 

cameraDetectionState OBJECT-TYPE 


detectionIsNotDisabled (1), 

detectionIsDisabled (2) } 



DESCRIPTION 

" A camera can be enabled/disabled so that it may be used for 

other purposes such as surveillance. A disabled camera puts the associated 

zones in failsafe mode. If a pole has been hit and the camera is no longer 

looking at the traffic this can be used to put all the zones associated with 

that camera in failsafe mode. It can also be used for pan-tilt-zoom camera to 

disable detection so that the camera may be used for surveillance allowing the 

camera to look at areas other than the detection area. Enabling the camera 

places all the zones associated with that camera back into their defined 

detection mode. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.4" 





Page 117 

5.6.2.5 Zone List for Camera 

zoneListForCamera OBJECT-TYPE 




DESCRIPTION 

" This is a bit map where a 1 in a bit position indicates that 

zone is with the selected camera. The least significant bit (bit 0) of the 

first octet (byte) shall represent zone 1 and bit 6 of the 32 nd octet (byte) 

shall represent zone 255. The most significant bit of the 32 nd octet (byte) is 

reserved and shall not be set. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.5" 


5.6.2.6 Baseline Image 

baselineImage OBJECT-TYPE 


notSupported (1), 

supportedAndAvailable (2), 

supportedButNotAvailable (3) } 



DESCRIPTION 

" Determines whether the machine vision camera supports a baseline 

image and the status of that image. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.6" 


5.6.2.7 Snapshot Image 

snapshotImage OBJECT-TYPE 


notSupported (1), 

supported (2) } 



DESCRIPTION 

" This data element determines whether the machine vision camera 

supports a snapshot image. 

notSupported(1) - Indicates that the machine vision camera does 

not support snapshot images. 

supported(2) - Indicates that the machine vision camera supports 

snapshot images. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.7" 


5.6.2.8 Camera Image Formats 

cameraImageFormat OBJECT-TYPE 




DESCRIPTION 

" Defines the types of image formats that the machine vision 

camera supports. 

 

bit 0 0 = NO, 1 = YES Indicates that the machine vision camera 

supports bitmap imagery; 

bit 1 0 = NO, 1 = YES Indicates that the machine vision camera 

supports JPEG imagery; 



Page 118 

bits 2..31 

Reserved. 

1.3.6.1.4.1.1206.4.2.4.5.2.1.8" 


5.6.3 Image Zone Number 

imageZoneNumber OBJECT-TYPE 




DESCRIPTION 

" The numerical label or number representing the sensor zone 

number that is associated with the image. A value of zero (0) indicates that 

no sensor zone number is selected. When read, this data element returns the 

last value written. 

1.3.6.1.4.1.1206.4.2.4.5.3" 


5.6.4 Image Type 

imageType OBJECT-TYPE 


snapshot (1), 

baseline (2) } 



DESCRIPTION 

" This data element set the type of image to generate: 

Snapshot(1) - Snapshot indicates to capture a current image to 

transmit; 

Baseline(2) - Baseline indicates to use the baseline image used 

to set up the system for transfer. 

1.3.6.1.4.1.1206.4.2.4.5.4" 


5.6.5 Image Overlay Type 

imageOverlayType OBJECT-TYPE 


none (1), 

thisZone (2), 

allZones (3), 

defaultOverlay (4) } 



DESCRIPTION 

" This data element sets the type of image overlay to generate: 

none(1) - No overlay is generated in to the image; 

thisZone(2) - Indicates that an overlay is generated in the 

image indicating the location of this zone. The overlay specifics 

are manufacturer dependent; 

allZones(3) - Indicates that an overlay is generated in the 

image indicating the location of all zones associated with the 

camera. The overlay specifics are manufacturer dependent; 

defaultOverlay(4) - Indicates the manufacturer generates its 

default overlay in to the image. 

1.3.6.1.4.1.1206.4.2.4.5.5" 





Page 119 

5.6.6 Image Format 

imageFormat OBJECT-TYPE 


bitmap (1), 

jpeg (2) } 



DESCRIPTION 

" Identifies what format to return the machine vision camera image 

in. 

1.3.6.1.4.1.1206.4.2.4.5.6" 


5.6.7 Image Quality 

imageQuality OBJECT-TYPE 




DESCRIPTION 

" This data element is used to select the image quality. The 

meaning varies based on the Image Format. A value of 100 selects the highest 

quality available. A value of 1 selects the lowest quality available. Lower 

quality may mean smaller more compressed images. Some image formats do not 

support variable image quality so the value is ignored. If a manufacturer 

supports only two image qualities for a specific image format then values 1 to 

50 should select the lower quality while values 51 to 100 should select the 

higher quality. 

1.3.6.1.4.1.1206.4.2.4.5.7" 


5.6.8 Build Image 

buildImageCmd OBJECT-TYPE 


buildImage (1), 

cancelBuildInProgress (2) } 



DESCRIPTION 

" Writing the value buildImage to this data element commands the 

sensor to build an image based on the preceding parameters. A read of this 

data element always returns the last written. Values for this command are: 

buildImage(1) - This command shall cause the unit to build an 

image that can be read. 

cancelBuildInProgress(2) - This command shall cause the unit to 

cancel the current building process. 

1.3.6.1.4.1.1206.4.2.4.5.8" 


5.6.9 Build Image Status 

buildImageStatus OBJECT-TYPE 


noImage (1), 

buildingImage (2), 

imageReady (3), 

genericError (4), 

invalidParameter (5), 

noCameraForZone (6), 

multipleCamerasForZone (7), 



Page 120 

imageReceiveError (8), 

buildPending (9) } 



DESCRIPTION 

" Reading the value buildImageStatus from this data element yields 

the status of the current image to be read: 

noImage(1) - No Image is available for reading. This is the 

initial state if the buildImageCmd command has not been issued; 

buildingImage(2) - The sensor is in the progress of building the 

image. It is not ready yet; 

imageReady(3) - The image is ready for transfer. The last build 

command completed successfully; 

genericError(4) - An error occurred generating an image and 

there is not a more descriptive status code available to describe 

it; 

invalidParameter(5) - One of the Image Setup Data parameters is 

invalid; 

noCameraForZone(6) - The zone selected does not have a camera 

associated with it; 

multipleCamerasForZone(7) - There is more than one camera 

associated with the zone. To build an image you must select a 

zone with one and only one camera; 

imageReceiveError(8) - The sensor is having trouble receiving an 

image from its camera. This could be bad sync or other 

transmission problems; 

buildPending(9) - The sensor can not begin the requested build 

at this time. The build begins when the blocking condition 

was ended. This can occur if the current image is in use (e.g., 

being transferred). 

1.3.6.1.4.1.1206.4.2.4.5.9" 


END 




Page 121 

Annex A 

REQUIREMENTS TRACEABILITY MATRIX (RTM) 

NORMATIVE 

Requirement ID Requirement Dialog ID Dialog Object ID Object 

3.3 Operational Environment Requirements 

3.3.1 Support Live Data 

3.3.1.1 Retrieve Data 


3.3.1.2 Deliver Data 


3.3.1.3 Data Retrieval and Data Delivery Action Performance 


4.2.2 Generic SNMP Get-Next Interface 


3.3.2 Support Batched Data 



5.2.4 maxSensorZones 

5.4.3.1 numSampleDataEntries 

5.4.3.2 numSensorZoneClass 

5.4.4.3 sampleEndTime 

5.4.4.4 sampleVolumeData 

5.4.4.5 samplePercentOccupancy 

5.4.4.6 sampleSpeedData 

5.4.4.7 sampleZoneStatus 

5.4.4.8 sampleSequenceNumber 

© 2010 AASHTO / ITE / NEMA Copy Per RTM Distribution Notice


Page 122 


3.4 Data Exchange Requirements 

3.4.1 Manage the TSS Configuration 

3.4.1.1 Identify TSS 

3.4.1.1.1 Determine Sensor Technology 


5.2.7 sensorTechnology 

3.4.1.1.2 Determine Manufacturer 


1201:2005 – 2.2.3.3 moduleMake 

3.4.1.1.3 Determine Model 


1201:2005 – 2.2.3.4 moduleModel 

3.4.1.1.4 Determine Firmware Version 


1201:2005 – 2.2.3.5 moduleVersion 

3.4.1.1.5 Determine Hardware Version 



3.4.1.1.6 Determine Protocol Version 



3.4.1.1.7 Determine Standards Revision Version 




3.4.1.2.1 Determine Maximum Number of Sensor Zones 



Copy Per RTM Distribution Notice © 2010 AASHTO / ITE / NEMA


Page 123 


3.4.1.2.2 Determine Maximum Number of Historical Data Entries per Sensor Zone 


5.2.8 maxSampleDataEntries 

3.4.1.2.3 Determine Maximum Number of Outputs 


5.3.1 maxOutputNumber 

3.4.1.2.4 Determine Maximum Number of Output Groups 


5.3.3 maxOutputGroups 

3.4.1.2.5 Determine Type of Occupancy Used 


5.2.3 sensorSystemOccupancyType 

3.4.1.2.6 Determine Availability of a Real Time Clock (RTC) 


5.2.6 clockAvailable 

3.4.1.2.7 Determine if Real Time Clock (RTC) Supports Daylight Saving Time (DST) 


1201:2005 – 2.4.2 global DaylightSaving 

3.4.1.2.8 Determine Maximum Number of Classes 





3.4.1.2.9 Determine Maximum Number of Characters for Labels 


5.2.9 maxNumberOfCharacters 

3.4.1.2.10 Determine Optional Features 


5.2.10 functionalCapabilities 



Page 124 


3.4.1.3 Control the TSS 

3.4.1.3.1 Restart the TSS 


5.2.1 sensorSystemReset 

5.2.2 sensorSystemStatus 

3.4.1.3.2 Reinitialize User Settings 




3.4.1.3.3 Restore Factory Defaults 




3.4.1.3.4 Retune 




3.4.1.3.5 Resynchronize Sampling Periods 




3.4.1.3.6 Short Diagnostics 




3.4.1.3.7 Full Diagnostics 






Page 125 


3.4.1.3.8 Execute Pending Configuration 

4.3.1.3 Execute Pending Configuration Change 



3.4.1.3.9 Abort Pending Configuration 

4.3.1.4 Abort Pending Configuration 



3.4.1.3.10 Validate Pending Configuration 

4.3.1.5 Validate a Pending Configuration 



3.4.1.3.11 Get External Arming Inputs 

4.3.1.9 Retrieve External Arming Inputs 

5.2.11 externalArmingInputs 

3.4.1.3.12 Set External Arming Inputs 

4.3.1.8 Configuring External Arming Inputs 

5.2.11 externalArmingInputs 

3.4.1.3.13 Set Pending Configuration File Name 


5.2.13 pendingConfigurationFileName 

3.4.1.3.14 Get Pending Configuration File Name 


5.2.13 pendingConfigurationFileName 


3.4.1.4.1 Get Date and Time 


NTCIP 1201 v03 Sec. 2.4.1 globalTime 

NTCIP 1201 v03 Sec. 2.4.6 controllerStandardTImeZone 



Page 126 


NTCIP 1201 v03 Sec. 2.4.7 controllerLocalTime 

3.4.1.4.2 Get Daylight Saving Time (DST) Mode 


NTCIP 1201 v03 Sec. 2.4.2 globalDaylightSaving 

3.4.1.4.3 Set Date and Time 


NTCIP 1201 v03 Sec. 2.4.1 globalTime 

NTCIP 1201 v03 Sec. 2.4.6 controllerStandardTimeZone 

NTCIP 1201 v03 Sec. 2.4.7 controllerLocalTime 

3.4.1.4.4 Set Daylight Saving Time (DST) Mode 


NTCIP 1201 v03 Sec. 2.4.2 globalDaylightSaving 

3.4.1.5 Manage Sensor Zones 

3.4.1.5.1 Get Zone Options 




5.2.5.2 sensorZoneOptions 

3.4.1.5.2 Get Zone Options Status 




5.2.5.3 sensorZoneOptionsStatus 

3.4.1.5.3 Get Zone Sample Period 




5.2.5.4 sensorZoneSamplePeriod 



Page 127 


3.4.1.5.4 Get Zone Label 




5.2.5.5 sensorZoneLabel 

3.4.1.5.5 Get Zone Boolean AND Zones 




5.2.5.6 sensorZoneAndOperator 

3.4.1.5.6 Get Zone Boolean OR Zones 




5.2.5.7 sensorZoneOrOperator 

3.4.1.5.7 Set Zone Options 




5.2.5.2 sensorZoneOptions 

3.4.1.5.8 Set Zone Sample Period 




5.2.5.3 sensorZoneOptionsStatus 

5.2.5.4 sensorZoneSamplePeriod 



Page 128 


3.4.1.5.9 Set Zone Label 




5.2.5.5 sensorZoneLabel 

3.4.1.5.10 Set Zone Boolean AND Zones 




5.2.5.6 sensorZoneAndOperator 

3.4.1.5.11 Set Zone Boolean OR Zones 




5.2.5.7 sensorZoneOrOperator 

3.4.1.5.12 Get Paired Zone 




5.2.5.8 sensorZonePairedZone 

3.4.1.5.13 Get Paired Zone Options 




5.2.5.9 sensorZonePairedZoneOptions 



Page 129 


3.4.1.5.14 Get Paired Zone Spacing 




5.2.5.10 sensorZonePairedZoneSpacing 

3.4.1.5.15 Get Speed Correction Factor 




5.2.5.11 sensorZoneSpeedCorrectionFactor 

3.4.1.5.16 Set Paired Zone 




5.2.5.8 sensorZonePairedZone 

3.4.1.5.17 Set Paired Zone Options 




5.2.5.9 sensorZonePairedZoneOptions 

3.4.1.5.18 Set Paired Zone Spacing 




5.2.5.10 sensorZonePairedZoneSpacing 



Page 130 


3.4.1.5.19 Set Speed Correction Factor 




5.2.5.11 sensorZoneSpeedCorrectionFactor 

3.4.1.5.20 Get Sensor Zone Average Vehicle Length 




5.2.5.12 sensorZoneAvgVehicleLength 

3.4.1.5.21 Get Sensor Zone Length 




5.2.5.13 sensorZoneLength 

3.4.1.5.22 Set Sensor Zone Average Vehicle Length 




5.2.5.12 sensorZoneAvgVehicleLength 

3.4.1.5.23 Set Sensor Zone Length 




5.2.5.13 sensorZoneLength 



Page 131 


3.4.1.5.24 Get Sensor Zone Loop Layout 




5.5.1.4 sensorZoneLoopLayout 

3.4.1.5.25 Set Sensor Zone Loop Layout 




5.5.1.4 sensorZoneLoopLayout 

3.4.1.5.26 Set Zone Sensitivity Mode 




5.5.1.1 zoneSensitivityMode 

3.4.1.5.27 Set Zone Sensitivity 




5.5.1.2 zoneSensitivity 

3.4.1.5.28 Set Sensor Zone Frequency Range 




5.5.1.3 zoneFrequencyRange 



Page 132 


3.4.1.5.29 Get Zone Sensitivity Mode 




5.5.1.1 zoneSensitivityMode 

3.4.1.5.30 Get Zone Sensitivity 




5.5.1.2 zoneSensitivity 

3.4.1.5.31 Get Sensor Zone Frequency Range 




5.5.1.3 zoneFrequencyRange 

3.4.1.5.32 Get Zone Output Mode 




5.2.12.1 sensorZoneOutputMode 

3.4.1.5.33 Get Output Max Presence Time 




5.2.12.2 sensorZoneMaxPresenceTime 



Page 133 


3.4.1.5.34 Get Output Delay Time 




5.2.12.3 sensorZoneOutputDelayTime 

3.4.1.5.35 Get Output Extension Time 




5.2.12.6 sensorZoneOutputExtendTime 

3.4.1.5.36 Set Zone Output Mode 




5.3.12.1 sensorZoneOutputMode 

3.4.1.5.37 Set Output Max Presence Time 




5.2.12.2 sensorZoneMaxPresenceTime 

3.4.1.5.38 Set Output Delay Time 




5.2.12.3 sensorZoneOutputDelayTime 



Page 134 


3.4.1.5.39 Set Output Delay Enables 




5.2.12.5 sensorZoneOutputDelayEnables 

3.4.1.5.40 Set Output Extension Time 




5.2.12.6 sensorZoneOutputExtendTime 

3.4.1.5.41 Set Output Extension Enables 




5.2.12.8 sensorZoneOutputExtendEnables 

3.4.1.5.42 Get Output Delay Mode 




5.2.12.4 sensorZoneOutputDelayMode 

3.4.1.5.43 Set Output Delay Mode 




5.2.12.4 sensorZoneOutputDelayMode 



Page 135 


3.4.1.5.44 Get Output Extension Mode 




5.2.12.7 sensorZoneOutputExtendMode 

3.4.1.5.45 Set Output Extension Mode 




5.2.12.7 sensorZoneOutputExtendMode 

3.4.1.5.46 Get Zone Output Sequenced 




5.2.12.9 sensorZoneOutputSequenced 

3.4.1.5.47 Set Zone Output Sequenced 




5.2.12.9 sensorZoneOutputSequenced 

3.4.1.5.48 Get Output Delay Enables 




5.2.12.5 sensorZoneOutputDelayEnables 



Page 136 


3.4.1.5.49 Get Output Extension Enables 




5.2.12.8 sensorZoneOutputExtendEnables 

3.4.1.5.50 Get No Activity Fault Time 




5.2.5.15 sensorZoneNoActivityFaultTime 

3.4.1.5.51 Get Max Presence Fault Time 




5.2.5.16 sensorZoneMaxPresenceFaultTime 

3.4.1.5.52 Get Erratic Counts Fault Time 




5.2.5.17 sensorZoneErraticCountsFaultTime 

3.4.1.5.53 Get Erratic Counts Threshold 




5.2.5.18 sensorZoneErraticCountsThreshold 



Page 137 


3.4.1.5.54 Set No Activity Fault Time 




5.2.5.15 sensorZoneNoActivityFaultTime 

3.4.1.5.55 Set Max Presence Fault Time 




5.2.5.16 sensorZoneMaxPresenceFaultTime 

3.4.1.5.56 Set Erratic Counts Fault Time 




5.2.5.17 sensorZoneErraticCountsFaultTime 

3.4.1.5.57 Set Erratic Counts Threshold 




5.2.5.18 sensorZoneErraticCountsThreshold 

3.4.1.6 Manage Outputs 

3.4.1.6.1 Get Output Sensor Zone 



5.3.2.1 outputNumber 

5.3.2.2 outputSensorZoneNumber 



Page 138 


3.4.1.6.2 Get Output Failsafe Mode 




5.3.2.3 outputFailsafeMode 

3.4.1.6.3 Get Output Mode Status 




5.3.2.4 outputModeStatus 

3.4.1.6.4 Get Output Label 




5.3.2.5 outputLabel 

3.4.1.6.5 Set Output Sensor Zone 




5.3.2.2 outputSensorZoneNumber 

3.4.1.6.6 Set Output Failsafe Mode 




5.3.2.3 outputFailsafeMode 



Page 139 


3.4.1.6.7 Set Output Label 




5.3.2.5 outputLabel 

3.4.1.6.8 Get Output Arming Enables 




5.3.2.6 outputArmingEnables 

3.4.1.6.9 Get Output Arming Mode 





3.4.1.6.10 Set Ouput Arming Enables 





3.4.1.6.11 Set Ouput Arming Mode 





3.4.1.7 Manage Camera 

3.4.1.7.1 Set Disable Detection 


5.6.2.4 cameraDetectionState 



Page 140 


3.4.1.7.2 Get Disable Detection 


5.6.2.4 cameraDetectionState 

3.4.1.7.3 Set the Build Image Parameter 

4.3.5.1 Set Build Image Parameter 

5.6.3 imageZoneNumber 

5.6.4 imageType 

5.6.5 imageOverlayType 

5.6.6 imageFormat 

5.6.7 imageQuality 

5.6.8 buildImageCmd 

3.4.1.7.4 Set Cancel Build In-Progress 


5.6.8 buildImageCmd 

3.4.1.7.5 Get Baseline Image Status 


5.6.2.6 baselineImage 

3.4.1.7.6 Get Camera Image Formats Supported 


5.6.2.8 cameraImageFormat 

3.4.1.7.7 Set Image Zone Number 



3.4.1.7.8 Get Image Zone Number 



3.4.1.7.9 Set Image Type 





Page 141 


3.4.1.7.10 Get Image Type 



3.4.1.7.11 Set Image Overlay Type 



3.4.1.7.12 Get Image Overlay Type 



3.4.1.7.13 Set Image Quality 



3.4.1.7.14 Get Image Quality 



3.4.1.7.15 Set Camera Image Format 



3.4.1.7.16 Get Camera Image Format 



3.4.1.7.17 Get Camera Name Label 


5.6.2.2 cameraNameLabel 

3.4.1.7.18 Set Camera Name Label 


5.6.2.2 cameraNameLabel 



Page 142 


3.4.1.7.19 Get Maximum Camera Count 


5.6.1 maxCameraCount 

3.4.2 Monitor the Current Status 

3.4.2.1 Get System Status 



3.4.2.2 TSS Sensor Status 


5.2.5.14 sensorZoneStatus 

3.4.2.2.1 Get Zone Inductance 




5.5.3.1 zoneInductance 

3.4.2.2.2 Get Zone Frequency 




5.5.3.2 zoneFrequency 

3.4.2.2.3 Get Zone Inductance Change 




5.5.3.3 zoneInductanceChange 



Page 143 


3.4.2.2.4 Get Zone Fault History 




5.5.3.4 zoneFaultHistory 

3.4.2.2.5 Get Zone Fault Count 




5.5.3.5 zoneFaultCount 

3.4.2.2.6 Get Zone Status 




5.2.5.14 sensorZoneStatus 

3.4.2.2.7 Get Image Reception Diagnostics 


5.6.2.3 imageReceptionDiagnostic 

3.4.2.2.8 Get Image 


5.6.2.7 snapshotImage 

3.4.2.2.9 Get Zone List for Camera 


5.6.2.5 zoneListForCamera 

3.4.2.2.10 Get Zone Percent Inductance Change 


5.5.3.6 zonePercentInductanceChange 



Page 144 


3.4.2.2.11 Get Image Status 


5.6.9 buildImageStatus 


3.4.2.3.1 Get Output Group Output State 


5.3.4.1 outputGroupNumber 

5.3.4.2 outputGroupOutputState 

3.4.3 Collection of Sample Data 

3.4.3.1 Retrieve Historical Sample Data from TSS 

3.4.3.1.1 Get Historical Sample End Time 






5.4.4.3 sampleEndTime 

3.4.3.1.2 Get Historical Sample Volume 






5.4.4.4 sampleVolumeData 



Page 145 


3.4.3.1.3 Get Historical Sample Percent Occupancy 






5.4.4.5 samplePercentOccupancy 

3.4.3.1.4 Get Historical Sample Speed 






5.4.4.6 sampleSpeedData 

3.4.3.1.5 Get Historical Sample Zone Status 






5.4.4.7 sampleZoneStatus 

3.4.3.1.6 Get Historical Sequence Number 








Page 146 


3.4.3.1.7 Get Zone Class Label 

3.4.3.1.8 Get Number of Sample Data Entries 

3.4.3.1.9 Get Number of Sensor Zone Classes 

4.3.3.5 Retrieve Sensor Zone Class Labels 



5.4.5.1 zoneClassLabel 






3.5 Multi-Version Interoperability (MVI-Backward Compatibility) 




3.5.1 Most Recent NTCIP 1209:2005 (version v01) Conformant Data Sample Table 



4.3.3.6 

4.3.3.6 

Retrieve Most Recent NTCIP 1209:2005 (version v01) Conformant Data Sample for a Sensor 

Zone 


5.4.1.1 endTime 


Zone 


5.4.1.2 volumeData 



Page 147 





4.3.3.6 

4.3.3.6 


Zone 


5.4.1.3 percentOccupancy 


Zone 


5.4.1.4 speedData 

4.3.3.6 

Retrieve Most Recent NTCIP 1209: 2005 (version v01) Conformant Data Sample for a Sensor 

Zone 


5.4.1.5 zoneStatus 

3.5.2 Retrieve Version v01 Conformant Historical Sample Data Table 

3.5.2.1 Get End Time 



4.3.3.7 Retrieve NTCIP 1209:2005 (version v01) Conformant Historical Sample Data for a Sensor Zone 


5.4.2.1 endTimeBuffer 



5.4.2.2 volumeDataBuffer 



5.4.2.3 percentOccupancyBuffer 



Page 148 





5.4.2.4 speedDataBuffer 




5.4.2.5 zoneStatusBuffer 


3.5.3.1 Get Output Mode 



5.5.2.1 zoneOutputMode 

3.5.3.2 Get Max Presence Time 



5.5.2.2 zoneMaxPresenceTime 

3.5.3.3 Get Output Delay Time 



5.5.2.3 zoneOutputDelayTime 

3.5.3.4 Get Output Extend Time 



5.5.2.4 zoneOutputExtendTime 

3.5.3.5 Get Output Delay Enable 



5.5.2.6 zoneOutputDelayEnable 



Page 149 


3.5.3.6 Get Output Extend Enable 



5.5.2.5 zoneOutputExtendEnable 

3.5.3.7 Set Output Mode 



5.5.2.1 zoneOutputMode 

3.5.3.8 Set Max Presence Time 



5.5.2.2 zoneMaxPresenceTime 

3.5.3.9 Set Output Delay Time 



5.5.2.3 zoneOutputDelayTime 

3.5.3.10 Set Output Extend Time 



5.5.2.4 zoneOutputExtendTime 

3.5.3.11 Set Output Delay Enable 



5.5.2.6 zoneOutputDelayEnable 

3.5.3.12 Set Output Extend Enable 



5.5.2.5 zoneOutputExtendEnable 



Page 150 

Annex B 

OBJECT TREE 

Figure 7 provides a graphical representation of the Traffic Sensor System Object Tree. 




Page 151 

tss (4) 

tssSystemSetup (1) tssControl (2) 

tssDataCollection 

(3) 

tssInductiveLoop 

(4) 

tssMachineVision 

(5) 

sensorSystemReset 

(1) 

maxOutputNumber 

(1) 

dataCollectionTable 

(1) 

loopSensorSetupTa 

ble (1) 

maxCameraCount 

(1) 

sensorSystemStatu 

s (2) 

outputConfiguration 

Table (2) 

dataBufferTable (2) 

loopOutputConditio 

ningTable (2) 

machineVisionCam 

eraTable (2) 

sensorSystemOccu 

pancyType (3) 

maxOutputGroups 

(3) 

zoneSequenceTabl 

e (3) 

loopSystemStatusT 

able (3) 

imageZoneNumber 

(3) 

maxSensorZones 

(4) 

outputGroupTable 

(4) 

sampleDataTable 

(4) 

imageType (4) 

sensorZoneTable 

(5) 

zoneClassTable (5) 

imageOverlayType 

(5) 

clockAvailable (6) 

imageFormat (6) 

sensorTechnology 

(7) 

imageQuality (7) 

maxSampleDataEnt 

ries (8) 

buildImageCmd (8) 

MaxNumberOfChar 

acters (9) 

buildImageStatus 

(9) 

functionalCapabilitie 

s (10) 

externalArmingInput 

s (11) 

outputConditioningT 

able (12) 

Diagram Notes: 

1) Not all levels of the tree are shown. 

2) Highlighted data elements have been deprecated. 

pendingConfiguratio 

nFileName (13) 

Figure 7 Object Tree for NTCIP 1209 v02 

©2010 AASHTO / ITE / NEMA Do Not Copy Without Written Permission


Page 152 

Annex C 

TEST PROCEDURES 

Annex C is a placeholder for test procedures content in a future major version. 




Page 153 

Annex D 

DOCUMENTATION OF REVISIONS 

Annex D identifies changes that have been made to NTCIP 1209 v02 that required the deprecation of 

objects. NTCIP makes reasonable efforts to ensure that NTCIP standards accommodate multi-version 

interoperability (MVI-backward compatibility) to the extent possible. When revisions are required, 

problematic objects are deprecated and, in most cases, are replaced with new objects. Annex D identifies 

why many of these changes have been made. To maintain MVI for legacy implementations, objects with 

a STATUS value of “deprecated” may require support. When necessary to support legacy 

implementations, required support for objects with a STATUS value of “deprecated” is indicated using the 

Profile Implementation Conformance Statement (PICS) or Protocol Requirements List (PRL). 

D.1 SYSTEMS ENGINEERING PROCESS 

Major changes have been made to NTCIP 1209 v02 to embrace the principles of the Systems 

Engineering Process (SEP). SEP includes the definition of the user needs, functional requirements, 

dialogs, and a requirements traceability matrix in addition to the already existing management information 

base (MIB). The conformance group definitions and the conformance statement contained in NTCIP 

1209:2005 (version v01) were replaced by the Protocol Requirements List (PRL) in Section 3, which 

allows a user to specify which functions are to be supported by a TSS. 

D.2 GENERAL MIB CHANGES 

General edits have been made to the MIB header in NTCIP 1209 v02 to reflect updates to imported MIBs. 

All DESCRIPTION fields have been updated to conform to NTCIP 8004 v02. Additionally, many 

DESCRIPTION fields have received additional clarifications and explanations to remove ambiguities. 

and subfields were removed from the DESCRIPTION field. 

References to objects defined in NTCIP 1201 v03 are now made through the RTM rather than through 

comments in the MIB. 

Textual conventions BITMAP8, BITMAP16, BITMAP32, BITMAP64, BITMAP96, and BITMAP256 were 

used for data elements that were intended to be used as bitmapped data instead of OCTET STRING 

(SIZE(1)), OCTET STRING (SIZE(2)), OCTET STRING (SIZE(4)), OCTET STRING (SIZE(8)), OCTET 

STRING (SIZE(12)), and OCTET STRING (SIZE(32)), respectively. This adds clarity to the use of data 

elements without affecting their size or compilation. 

D.3 DEPRECATED DATA COLLECTION TABLE 

The dataCollectionTable data element and its subordinates were deprecated because they did not 

adequately support the user need for classes and additional sample periods (minimum of four). A new 

capability is supported by the combination of the zoneSequenceTable and the sampleDataTable, entry 

number 2. 

D.4 DEPRECATED DATA BUFFER TABLE 

The dataBufferTable data element and its subordinates were deprecated because they did not support 

classes. "In-progress" data is now supported through the combination of the zoneSequenceTable and the 

sampleDataTable, entry number 3. 

D.5 DEPRECATED LOOP OUTPUT CONDITIONING TABLE 

The loopOutputConditioningTable and its subordinates were deprecated because they did not support 

use in other sensor technologies. This capability is now in the outputConditioningTable data element. 

©2010 AASHTO / ITE / NEMA Do Not Copy Without Written Permission


Page 154 

D.6 ADDED MACHINE VISION DATA ELEMENTS 

NTCIP 1209 v02 supports general transportation sensing capabilities. It also explicitly provides data 

elements to support inductive loop and machine vision technologies (see tssInductiveLoop and 

tssMachineVision). Machine vision data elements were added to NTCIP 1209 v02. 

D.7 ADDITIONAL DATA ELEMENTS 

In addition to machine vision, data elements were added to: 

a) allow output conditioning on multiple technologies, 

b) support classes, 

c) support multiple sampling periods, 

d) support Arming Inputs, and 

e) support fault thresholds. 

The following data elements were added to the MIB, and may have subordinate data elements that are 

not listed. 

a) sensorSystemReset—Added enumerations executePendingConfiguration, 

abortPendingConfiguration, validatePendingConfiguration, and noResetInProgress. 

b) sensorSystemStatus—Added enumerations pendingConfigurationChange, 

validatingPendingConfiguration, DiagError, actvieConfigError, and pendingConfigError. 

c) sensorSystemOccupancyType—Added enumeration normalizedPointOccupancy. 

d) sensorZoneTable—Added data elements sensorZonePairedZone, sensorZonePairedZoneOptions, 

sensorZonePairedZoneSpacing, sensorZoneSpeedCorrectionFactor, sensorZoneAvgVehicleLength, 

sensorZoneLength, sensorZoneStatus, sensorZoneNoActivityFaultTime, 

sensorZoneMaxPresenceFaultTime, sensorZoneErraticCountsFaultTime, and 

sensorZoneErraticCountsThreshold. 

e) tssSystemSetup—Added sensorTechology, maxSampleDataEntries, maxNumberOfCharacters, 

functionalCapabilities, externalArmingInputs, outputConditioningTable, and 

pendingConfigurationFileName. 

f) outputConfigurationTable—Added outputArmingEnables and outputArmingMode. 

g) tssDataCollection—Added zoneSequenceTable, sampleDataTable, and zoneClassTable. 

h) loopSensorSetupTable—Added sensorZoneLoopLayout. 

i) loopSystemStatusTable—Added zonePercentInductanceChange. 

§

Recommended Standard of NTCIP 1209 v02.17 - Institute of ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?