Module 49 - T312
T312: Applying Your Test Plan to a Transportation Sensor System (TSS) Based on the NTCIP 1209 Standard v02
HTML of the Student Supplement
(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)
T312: Applying Your Test Plan to a Transportation Sensor System (TSS) Based on the NTCIP 1209 Standard v02
Table of Contents
Introduction/Purpose - 2
Outlines for TSS Communication Test Reporting - 2
Reference to Other Standards - 4
Glossary - 4
References - 8
Study Questions - 8
1. Introduction/Purpose
This module assists user agencies in their efforts to create test documentation specific to their transportation sensor system (TSS) needs based on the National Transportation Communications for Intelligent Transportation Systems Protocol (NTCIP) 1209 v02 Standard. At a time when connectivity and data sharing are essential, the NTCIP 1209 Standard provides a rich data set for communicating TSS information. While NTCIP standards for actuated signal control (ASC) and ramp metering control (RMC) supply some limited sensor data communications indirectly through those systems, NTCIP 1209 provides the means to configure, control, monitor, and collect data from TSSs directly. Used both publicly and commercially, TSS information enables transportation system managers and operators to improve traffic flow and public safety in a variety of ways. Prior to developing test documentation specific to their TSS needs, users are expected to be knowledgeable about the NTCIP 1209 v02 Standard and testing methodologies. The agency is also expected to have developed its own user needs and requirements related to the NTCIP 1209 Standard.
This module is based on the Institute of Electrical and Electronics Engineers (IEEE 829) architecture for testing. It reviews both sample test documentation created prior to testing and sample test documentation produced after performing the tests. It also guides agencies in verifying that delivered products comply with their NTCIP specifications.
2. Outlines for TSS Communication Test Reporting
(Extended Text Description: The graphic is arranged in three vertical areas or levels on the slide. At first level (top of slide), there is a rectangle about 10 times as wide as it is tall made with solid lines and extending about 2/3 of the slide. The rectangle is labeled "Test Execution." To the right of the Test Execution rectangle is a multiple document labeled "TSS Comm Interim Test Status Report." There is a thin solid arrow extending from the Test Execution rectangle to the TSS Comm Interim Test Status Report document. In the second level, spaced evenly horizontally below the Test Execution rectangle, are two multiple documents that are labeled "TSS Comm Test Log" and "TSS Comm Test Incident Report *." There are thin solid arrows extending from the Test Execution rectangle to the TSS Comm Test Log and the TSS Comm Test Incident Report documents respectively. In the third level, centered below the TSS Comm Test Log and TSS Comm Test Incident Report documents is the document "TSS Comm Test Report." There are thin solid arrows extending from TSS Comm Test Log and the TSS Comm Test Incident Report documents to the TSS Comm Test Report. There is separate text towards the bottom right of the slide as follows: "* IEEE 829-2008 allows "anomaly report" to be replaced by problem, test incident, defect, trouble, issue, or error report." )
TSS Communications Test Log
1 Introduction
1.1 Document identifier
1.2 Scope
1.3 References
2 Details
2.1 Description
2.2 Activity and Event Entries
2.2.1 Execution Description
2.2.2 Procedure Results
2.2.3 Environmental Information
2.2.4 Anomalous Events
2.2.5 Incident Report Identifiers
3 General
3.1 Glossary
TSS Communications Test Incident Report
1 Introduction
1.1 Document identifier
1.2 Scope
1.3 References
2 Details
2.1 Summary
2.2 Date anomaly discovered
2.3 Context
2.4 Description of anomaly
2.5 Impact
2.6 Originator's assessment of urgency
2.7 Description of the corrective action
2.8 Status of the anomaly
2.9 Conclusions and recommendations
3 General
3.1 Glossary
TSS Communications Interim Test Status Report
1 Introduction
1.1 Document identifier
1.2 Scope
1.3 References
2 Details
2.1 Test status summary
2.2 Changes from plans
2.3 Test status metrics
3 General
3.1 Glossary
TSS Communications Test Report
1 Introduction
1.1 Document identifier
1.2 Scope
1.3 References
2 Details
2.1 Overview of test results
2.2 Detailed test results
2.3 Rationale for decisions
2.4 Conclusions and recommendations
3 General
3.1 Glossary
3.2 Document change procedures and history
3. Reference to Other Standards
4. Glossary
Term | Definition |
---|---|
Agency Specification | A document that has been prepared by an agency to define requirements for a subject item or process when procured by the agency. |
Arming Enable | A selected state of an arming input bit or arming pin of the TSS that can be used to modify its operation. |
Arming Input Bit | An external event that is reported to the TSS using this protocol and used to modify its operation. |
Arming Pin | A physical input to the TSS that can be monitored and used to modify its operation. |
ASC | Actuated Signal Control |
Class | A subdivision of collected historical sample data. |
Compatibility | A condition that exists when two or more systems or components perform their required functions while sharing the same environment. |
Compliance | A condition that exists when an item meets all of the requirements of an agency specification. |
Conformance | A condition that exists when an item meets all of the mandatory requirements as defined by the standard. It can be measured on the standard as a whole, which means that it meets all mandatory (and applicable conditional) requirements of the standard or on a feature level (i.e., it conforms to feature X as defined in section X.X.X), which means that it meets all mandatory (and applicable conditional) requirements of the feature. |
ConOps | Concept of Operations |
Delay | A feature that allows the detection output from a TSS detector to be deferred for a user set time period. |
Deprecated | 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. |
DST | Daylight Saving Time |
Extension | A feature that allows the detection output from a TSS detector to be lengthened for a user set time period. |
Fail-Safe Mode | Capable of compensating automatically and safely for a failure, as a mechanism or power source. |
Feature | A service provided by or behavior of the TSS. |
Firmware Version | A manufacturer-specified description for identifying the software currently embedded in the TSS. |
Hardware Version | A manufacturer-specified description for identifying the electronic components that comprise the TSS. |
ICD | Interface Control Document |
Interchangeability | 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) |
Interoperability | The ability of two or more systems or components to exchange information and use the information that has been exchanged. |
Live Data | A specific operational network configuration between the management station and the TSS through which 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, in which the management station has access to the "current" information available in the TSS. |
Management Information Base (MIB) | A structured collection or database of related managed objects defined using Abstract Syntax Notation One (ASN.1). |
Management Station | A remote computer (e.g., Traffic Management Center), local computer (e.g., laptop), or local controller (e.g., Traffic Controller). |
MVI | Multi-Version Interoperability (backward compatibility) |
Near Real-Time Data | Data that depict an event as it existed at the current time less the processing time. The data vary from real-time data because they depend on the type and speed of transmission. These data are useable for identifying changes in traffic flows. |
NTCIP | National Transportation Communications for Intelligent Transportation Systems (ITS) Protocol |
Normalized | Process of reducing sample data to a common denominator to accommodate comparison of the measured data. |
Occupancy | 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. |
Output | The condition of an on/off status generated by a change of state. |
Output Mode | There are two common output 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. |
PRL | Protocol Requirements List |
Protocol | 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. |
Protocol Version | A standardized description for identifying the version of the TSS standard to which the TSS is designed to conform. |
Requirement | 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. |
Requirements Traceability | The ability to follow or study the logical progression among the needs, requirements, and design details in a step-by-step fashion. |
RTC | Real Time Clock |
RTM | Requirements Traceability Matrix |
Sample Period | Duration of time in seconds when data for the zone are being collected. |
Sensitivity | The ability of the TSS to react to incoming signals, expressed as the minimum input signal required to produce an output signal. |
Sensitivity Mode | A characteristic of the loop detector being used. It is defined as either AL/L, AL/Vl, or AL. |
Sensor | A physical device used for sensing traffic. |
SEP | Systems Engineering Process |
SNMP | Simple Network Management Protocol |
SRS | Software Requirements Specification |
Transportation Sensor System (TSS) | Any system capable of sensing and communicating near real-time traffic parameters using NTCIP. |
User | A person who will utilize the system that is developed. |
User Need | 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. |
Virtual Zone | A logical combination of one or more zones to create a new zone with its own conditioning and arming enables. Combining zones into a single zone can be used to provide one output from many zones. It 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. |
Volume | The number of vehicles crossing a section of road per unit time at a selected period. |
Zone | An area in which traffic parameters can be measured and/or traffic data can be generated. |
Zone Options | Special settings for controlling the behavior of zones. |
5. References
6. Study Questions
1) Which of the following is a TRUE statement?
2) When bench testing the communications for a TSS, the primary objective is to:
3) True or False: The best way to start developing your test documentation is with a Test Design.
4) What is the most appropriate test document in which to include a Test Traceability Matrix (TTM)?
5) Which of the following is a TRUE statement?