The NTCIP 1200 series defines standardized data elements that can be exchanged between a traffic management center (or any other management station) and a field device. This document identifies and defines data elements that can be supported by multiple types of devices (e.g., actuated signal controllers, dynamic message signs, connected vehicle roadside units). 

All data elements defined in this document have been deprecated. Current data elements to fulfill a similar set of user needs can be found in ISO 26048-1. 

The data defined in this standard was originally defined using the Structure of Management Information Version 1 (SMIv1) format, as defined in RFC 1212, and intended for implementations using the Simple Network Management Protocol Version 1 (SNMPv1). This document migrates the original data element definitions to use SMIv2, as defined by RFC 2578, to enable its unambiguous exchange when using SNMPv3. 

This document does not apply to interfaces using SNMPv1 and the continued use of SNMPv1 is discouraged. New implementations should use data elements defined in ISO 26048-1. This document is intended to allow the data originally developed for SNMPv1 devices to be exchanged via an SNMPv3 interface. Specifically, this document is envisioned to address the interface between a management station and a proxy agent as shown in Figure 1. 

Focus of this standard

Figure 1 reflects the expectation that management stations will be upgraded to SNMPv3 before field devices due to their limited numbers, but the data defined in this document applies for any SNMPv3 interface using the previously defined data included in this document, even those where the field device is upgraded first.

The management station is typically a traffic management center but could be any device acting as a SNMPv3 command generator (e.g., a field technician's laptop, a connected vehicle roadside unit). The field device is the device that is to be controlled and/or monitored by the management station. The proxy agent is responsible for providing secure communications between the traffic management center to a location very near the field device where a level of physical security can be provided. The interface between the proxy agent and the field device is not addressed by this standard; however, the expectation is that this interface is likely either:  

an SNMPv1 interface (when the proxy agent is a separate physical device) or 

an application programming interface (when the proxy agent is implemented as a software routine within the field device).

The manager communicates to the proxy agent using legacy versions of NTCIP data (as defined by this document) contained in SNMPv3 requests. If the request contains valid security credentials for the requested data, the proxy agent translates the SNMPv3 request into a format understood by the field device (e.g., SNMPv1) and forwards it to the older field device. The field device responds to the request and the proxy agent translates this response into SNMPv3. The proxy agent could be internal or external to the field device.

Throughout the remainder of this document, the term "data element" is replaced with the term "object type" to align with SNMPv3 terminology.

The following documents are referenced by this document. At the time of publication, the editions indicated were valid.

Normative references contain provisions that, through reference in this text, constitute provisions of this document. 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.

Structure and Identification of Management Information (SMI) published (Pending)

Structure of Management Information Version 2 (SMIv2), April 1999

Textual Conventions for SMIv2, April 1999

Conformance Statements for SMIv2, April 1999

Management Information Base (MIB) for the Simple Network Management Protocol (SNMP), December 2002

Systems and software engineering – Vocabulary

Intelligent transport systems – Field device SNMP data interface – Part 1: Global objects

Other references are included to provide a more complete understanding of this document and its relationship to other documents.

Simple Transportation Management Framework Application Profile (Pending)

Procedures for Creating Management Information Base (MIB) Files published (Pending)

Telnet Protocol Specification

An Architecture for Describing Simple Network Management Protocol (SNMP) Management Framework, December 2002

Message Processing and Dispatching for the Simple Network Management Protocol (SNMP), December 2002

Simple Network Management Protocol (SNMP) Applications, December 2002

View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), December 2002

Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) , December 2002

Transport Mappings for the Simple Network Management Protocol (SNMP)

Guidelines for Authors and Reviewers of MIB Documents, September 2005

Transport Security Model for the Simple Network Management Protocol (SNMP), June 2009

Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP), July 2011 To Be Updated

Entity MIB (Version 4), May 2013

Intelligent transport systems — Data exchange involving roadside equipment communication — Part 2: Centre to field device communications using SNMP

Intelligent transport systems — Station and communications architecture

Traffic Controller Assemblies with NTCIP Requirements

For Internet Architecture Board (IAB) and Internet Engineering Task Force documents, contact:

Internet Architecture Board (IAB)
www.rfc-editor.org
www.rfc-editor.org/repositories.html 

Copies of NTCIP documents may be obtained from:

NTCIP Coordinator
National Electrical Manufacturers Association
1300 N.17th Street, Suite 1752
Rosslyn, Virginia 22209-3801
www.ntcip.org
e-mail: ntcip@nema.org

Draft amendments, which are under discussion by the relevant NTCIP Working Group, and amendments recommended by the NTCIP Joint Committee are available.

Obtain NEMA standards from:

National Electrical Manufacturers Association
1300 North 17th Street, Suite 1752
Rosslyn, Virginia 22209
www.nema.org

This document defines object types within a management information base (MIB) per the rules defined in NTCIP 8004, which is based on RFC 2578.

While user needs and requirements frequently correspond to the nodal structure, they may trace to objects that are not lexicographically ordered. For example, the scheduling actions requires support for objects under the dayPlan node and objects related to the specific action(s) to be scheduled.

For the purposes of this document, the following terms and definitions apply. Terms not defined here are in accordance with their definitions in NTCIP 8004. Systems and software engineering terms not defined here are used in accordance with their definitions in ISO/IEC/IEEE 24765. English words not defined here or in ISO/IEC/IEEE 24765 are used in accordance with their definitions in Webster's New Collegiate Dictionary.

actuated signal controller

central system, field device, etc., that supports NTCIP

writeable object types used to request real-time activation of a feature of a device

NOTE—In some cases, control objects can also be used to report status.

polynomial algorithm performed on a specified range of data resulting in a 16 or 32 bit value

daylight saving time

capability of a component

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. 

NOTE—See National Telecommunications and Information Administration, U.S. Department of Commerce.

writeable object type used to configure an SNMP agent where the parameter has sufficient interrelationships with other object types to typically require multiple SNMP set operations using multiple SetRequest messages or a complex validation check that might consume more time than is reasonable for a traditional SNMP response

writeable object type used to configure the SNMP agent where the parameter can be set and validated using a single SNMP set operation

transportation specific subnetwork layer protocol that was designed to enable communication between multiple devices on the same communications line/channel

NOTE—The protocol is considered a legacy design because the communication links for which it was designed are unlikely to be able to support the data demands of a secure environment.

Part of the legacy Transportation Management Protocols of the NTCIP effort.

NOTE—See NTCIP 1103. STMP provided a simple and bandwidth efficient mechanism to communicate with field devices.

NOTE—The protocol is considered a legacy design because the communication links for which it was designed are unlikely to be able to support the data demands of a secure environment.

read-only object that reports a condition monitored by the SNMP agent

Accepted system engineering processes detail that the first step in designing a system is to develop well-defined user needs within a concept of operations.

This concept of operations provides the reader with:

A detailed description of the scope of this document;

An explanation of how an ITS field device is expected to fit into the larger context of an ITS system;

A starting point in the procurement process; and

An understanding of the perspective of the designers of this document.

This section is intended for all readers of the document, including:

Transportation operations managers

Transportation operations personnel

Transportation engineers

System integrators

Device manufacturers

The first three categories of readers should find this section useful to understand how ITS field devices can be used in their system. For this audience, this section serves as the starting point in the procurement process. They become familiar with each feature covered by this document and determine whether that feature is appropriate for their implementation. If it is, then the agency specification requires the feature and the mandatory requirements related to that feature.

The last two categories of readers should find this section (and corresponding sections in device-specific standards) useful to gain a more thorough understanding as to why the more detailed requirements (e.g., as specified in later sections of this document) exist.

The ConOps, requirements, and traceability defined is only intended to cover elements of that have been previously defined in prior NTCIP documents. As all objects in this document  are deprecated, no attempt has been made to define systems engineering content for object-types that was not previously supported by such content.

Some might find the size of this document to be a bit intimidating. This section has been added to explain the purpose of each section and make its consumption more manageable.

A concept of operations describes a proposed system from the users' perspective. Typically, a concept of operations is used on a project to ensure that the system developers understand the users' needs. Within the context of NTCIP standards, it is used to document the intent of each feature for which the standard supports a communications interface. It also serves as the starting point for users to select which features may be appropriate for their project.

The concept of operations starts with a discussion of the current situation and problems that have led to the need to deploy systems covered by the scope of the standard and to the development of the standard itself. This discussion is presented in layman's terms such that both the potential users of the system and the system developers can understand and appreciate the situation.

The concept of operations then documents key aspects about the proposed system, including the:

Reference physical architecture — The reference physical architecture defines the overall context of the proposed system and defines which specific interface is addressed by this document. 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.

Architectural Needs – The architectural needs presents the issues and needs relative to the system architecture that have a direct impact on this document.

Features – The features identify and describe the various functions that users may want the device 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 form the basis of the traceability tables contained in Section 3 and Annex A.

The concept of operations concludes by describing the degree to which security issues have been addressed by this document and by providing a description of how this document relates to the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT).

The architectural needs and features are collectively called the user needs. Once the user needs are validated by the user community, functional requirements are developed. These are documented in Section 3.

This document defines data that could be exchanged between a management system (e.g., central system) and a proxy agent connected to an ITS field device. This document does not claim to address all of the capabilities or features offered by the ITS field device or management system.

It is also of utmost importance for the reader to understand that not all functionalities defined in this document must be supported by an implementation to claim conformance. Instead, the project-specific specifications that do reference and incorporate desired applicable functionalities from this document are the guiding requirements that determine compliance.

This document has been written with the assumption that the reader:

Has an interest in the applicability of the National Transportation Communications for ITS Protocols (NTCIP) for deploying ITS field devices;

Is involved in writing the specifications to procure ITS field devices;

Is involved in reviewing submittals to procure ITS field devices;

Is involved in the software development, be it the firmware of an ITS field device or the software of a management system;

Is involved in testing the ITS field devices and/or management system; or

Is involved in the operational use of ITS field devices.

This document contains the following main sections, which is based on the described systems engineering process:

Section 1 – Overview – This section provides the user with references, table of contents, glossary, and other information.

Section 2 – Concept of Operations – This section provides a description of user needs (needs for features and needs related to the operational environment) applicable to ITS field devices.

Section 3 – Functional Requirements – This section defines the functional requirements that address user needs. The user needs addressed are defined in either Section 2 of this document or within the Concept of Operations sections of other NTCIP 1200 series standards. It includes a Protocol Requirements List (a.k.a., User Needs to Requirements Table) to standardize the traceability for the user needs defined in this document. The table also includes default conformance requirements; device-specific standards (e.g., other documents within the NTCIP 1200 series) can alter these conformance requirements to meet the specific needs of those device types. 

Section 4 – Dialogs and Interface Specifications – This section describes how each functional requirement is fulfilled. The dialogs define the standardized procedures for a management system to manage an ITS field device. The interface specifications define the operations that are allowed by the ITS field device and how data elements are inter-related.

Section 5+ – Management Information Bases – These sections define the data elements (object-type definitions) exchanged during communications.

There are an additional six annexes, as follows:

Annex A – Requirements Traceability – This annex provides normative tables that define traceability among requirements dialogs, and objects as well as other details and constraints for implementations. 

Annex B – Object Tree and UML Class Diagrams – This annex is informative and provides class diagrams and a depiction of the high-level object tree showing the nodes and some of the scalar objects. The purpose of this object tree is to provide the user with a high-level orientation tool to navigate the data elements.

Annex C – Test Procedures – This annex is normative and contains standardized test procedures that are common among multiple device types.

Annex D – Summary of Changes – This annex is informative and documents the (significant) revisions in this document (NTCIP 1201 v04) that have been made since the previous major version (NTCIP 1201 v03).

Annex E – User Requests – This annex is informative and provides an explanation of user requests that are not addressed in this standard.

Annex F – FAQs – This annex is informative and provides answers to potential questions that a user of this document might have.

This document has been designed for different audiences. While every reader of the document is welcome to read all sections of the document, the following identifies the sections that might be most relevant to each class of readers.

General Interest Users: Sections 1, 2, and the Frequently Asked Questions (FAQ) annex.

Specifications Writers / Purchasers: Review Sections 1, 2, 3, and the FAQ annex

Submittal Reviewers: Sections 1, 2, 3, the FAQ annex, and the Requirements Traceability Matrix (RTM) annex.

Firmware/Software Developers: All Sections and Annexes

Testers: All Sections and Annexes

Operators: Sections 1, 2, and the Frequently Asked Questions (FAQ) annex.

Transportation system managers use ITS field devices in a variety of ways to improve transportation system operations. To perform their jobs, transportation system managers need to obtain data from the field (e.g., via sensors, cameras), implement traffic control policies (e.g., via gates, signals), and convey information to the traveling public (e.g., via message signs, RSUs). ITS field devices can be permanent, temporary, or transportable and can use a wide variety of communications media. This standard is intended to support all these environments.

Despite the varied nature of these devices, users expect every device to follow some basic principles in data exchange and there are advantages in standardizing some features (e.g., event logging) across device types. This standard focuses on the common user needs, requirements, and design elements that are common across many device types.

The enhancement of certain functions over time has caused certain objects to be deprecated and/or replaced. Most updates to NTCIP standards are mostly backwards compatible, meaning that:

Most objects remain current and

Objects deprecated by the new version can still be supported and exchanged by a field device claiming conformance to the new version (if the device supports the object and recognizing the limitations and issues that caused the object to be deprecated).

This document does not follow this rule because it is based on a different protocol (SNMPv3 rather than SNMPv1). As a result, the dialogs defined and referenced by this standard are not directly interoperable with prior NTCIP implementations. However, the two protocols are similar enough to allow for a relatively simple proxy agent to repackage data from previous NTCIP versions into the more secure SNMPv3 format in real-time. Proxy agents might offer a path to upgrade existing equipment to a largely secure environment more quickly than implementing all the objects that supersede the data defined in this standard. However, users should be aware that the data defined in this standard is considered deprecated and no longer reflects current recommended design. The newer design, defined within ISO 26048-1, improves data access control among authorized users, enhances features based on inputs from additional stakeholders, provides a structure that promotes better code reuse, and resolves various ambiguities and aging details of the standard. A proxy agent can be implemented as a device external to the controller or as internal functionality within the physical controller of the field device.

While most of the objects within this document have identical syntax to that previously defined for use in SNMPv1, some objects have minor revisions to address potential ambiguities and challenges in implementing the previously defined syntax within SNMPv3. For example, prior versions of NTCIP defined a few objects with a SYNTAX of INTEGER (0.. 4294967295). These objects have created problems with some SNMPv1 implementations, and this syntax is strictly prohibited in SNMPv3; as a result, within the MIBs defined in this document, these objects are defined with a SYNTAX of Unsigned32. This results in a different value in the "type" field of the encoding, but this is a relatively easy translation for a proxy agent to make when converting between the SNMPv1 and SNMPv3 formats (and can eliminate resulting ambiguities if the proxy is internal to the field device and does not need to convert to SNMPv1 format).

This document addresses the communications interface between a management station and the controller of an ITS field device.

This document covers a portion of the information flows identified in the "SU11: Field Equipment Maintenance" Service Package of the Architecture Reference for Cooperative and Intelligent Transportation (ARC-IT) version 9.2. Figure 2 depicts the relevant portions of the physical view of this service package.

Physical View of Reference Architecture

Figure 2 shows how a field device can interact with a variety of different systems (a.k.a., "management station") and in most cases, those systems have interactions with their human operators. This standard address aspects of the following three information flows:

field equipment commands

field equipment configuration settings

field equipment status

SU11 also indicates additional information flows directly between maintenance and construction field personnel and field system operators; however, these flows are through direct human interaction with the device (e.g., front panel, switches) and are not within the scope of this document. Likewise, SU11 depicts flows among the center and support systems that are not within the scope of this document. As a result, these flows have been omitted from Figure 2.

It is important to note that this document only addresses items that are common to many ITS field device types; specific device-type standards extend this definition to provide more specific functionality. Finally, it is important to note that the NTCIP standards only address the communications interface and that additional requirements will need to be defined to fully specify a device to meet all end-user needs for functionality, quality, performance, etc.

This document addresses the interface between an ITS field device and a management station (e.g., a central computer). To enable communications between these components, the transportation system manager needs to establish a communication system that links the ITS field device with a management station. For some systems, the cost of communications may be minimal and as such the system may be designed for constant polling; other systems may encounter significant costs for communicating with the ITS field device and as such the system may be designed to minimize data exchanges.

When deploying an ITS field device, the system designer must consider which of the following operational environments need to be supported.

The typical operational environment allows the management station to monitor and control the device by issuing requests (e.g., requests to access information, alter information, or control the device). In this environment, the device responds to requests from the management station (e.g., through the provision of live data, success/failure notice of information alteration, or success/failure of the command).

Some 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 to be placed into a log, which can then be uploaded later. For example, the operator may wish to maintain a log of when the cabinet door is opened.

The high-resolution data recording facility (sometimes referred to simply as the recording mechanism) provides a programmable method of collecting high-resolution records of the history of values of selected objects. These records are collected and retained under user-specified conditions. While this facility may appear to be very similar to the logging feature defined in 2.4.2, it provides a distinct function. The logging feature captures a snapshot of information when a trigger fires and stores the information in a log. In contrast, the recording-mechanism feature captures multiple snapshots, potentially at very short intervals and stores a series of these snapshots when a trigger fires (potentially recording snapshots prior to the trigger firing, if so configured). Thus, whereas the logging feature produces a single snapshot for each event, the recording mechanism captures a series of snapshots for each event.

As with the logging feature, the manager is responsible for retrieving the data in a timely manner; however, since the recording mechanism can record a large amount of data in a short period of time, retrieving the data in a timely manner is even more important. 

Users should be aware that this user need imposes significant processing requirements on the device.

In some operational environments, it may be desirable to have the ITS field device automatically transmit data to the management station when certain conditions occur. Under this scenario, a manager can program the conditions that trigger a transmission and the information that is reported to the management station when the specified condition occurs. An example is a manager that wants to be immediately notified whenever a cabinet door is opened.

Devices that exist on a point-to-multi-point communications channel will need to manage the configuration of the data link service.

Managers need to manage communications over the SNMPv1 interface on the other side of the proxy agent when one exists.

Internal proxy agents can use an API interface rather than an SNMPv1 interface, in which case, this item would not be needed by the user.

Some operational environments have limited data capacity because of limitations in the data rates of the media and/or because of multiple devices sharing the same communications channel. In such environments, the management station might exchange user-defined sets of data with the device so that data can be transmitted more efficiently over the network. A manager might need to monitor and configure this interface.

The intent of the download transaction feature is that a management station has a need to download several inter-related parameters to the controller. Because the parameters are inter-related, the parameters need to be set simultaneously for the controller to validate the set operation (e.g., the download may consist of a set of parameters, whose sum shall equal the sum of another set of parameters. and the management station wishes to change the sum for both sets). While normal SNMP set operations simultaneously set all objects contained within the request, it does not normally perform consistency checks on the multiple values being set and has limited size constraints. The database transaction feature was designed to overcome these limitations.

The parameters that require the use of the transaction mode are device-specific. Some devices may not require support of the transaction feature, while other devices may require SET operations on any parameter object to be set within the transaction mode.

When used, the feature allows a device to buffer a series of set operations on database parameters and to implement all operations simultaneously to properly perform controller consistency checks.

This section identifies and describes the various standardized user needs addressed by an ITS field device. The Protocol Requirements List (PRL) traces these features to relevant functional requirements of an ITS field device, as defined in Section 3.

A transportation system operator needs to be aware of basic information about each of its field devices, including its identity; capabilities; location; and status. This allows an operator to understand the context in which the device is operating.

In some operational environments, managers may want to run a run-time defined schedule based on a run-time defined day plan. For example, many signal controllers are configured to run different patterns based on time-of-day and day-of-week. This feature allows managers to define the day plan triggers that call actions (the actions are defined separately).

A transportation system operator may need to turn simple auxiliary devices on and off. For example, the ITS field device may be co-located with a warning sign equipped with flashing beacons; this feature would allow the ITS field device to activate and deactivate the beacons rather than requiring an additional controller at the site.

Unauthorized access to data can have detrimental effects on the transportation network. Unauthorized modification of data within a controller can impact the efficiency of the transportation network and potentially adversely impact the safety of operations. Unauthorized retrieval of data can expose information to unauthorized users that can potentially be used for nefarious purposes. The protection of data includes protecting data from unauthorized release to users who might be authorized to access other data within the device. All implementations need to control access to data.

Unauthorized access to data within a proxy agent can compromise the data within an attached field device. All implementations of a proxy agent are required to control access to data.

The relationship to the ITS National Architecture is defined in 2.3.1.

This section defines Functional Requirements that are common to many ITS field devices. The requirements are designed to fulfill the user needs defined in Section 2 of this document and/or other documents. This section includes:

A tutorial

The Protocol Requirements List (PRL) – A Functional Requirement is a requirement of a given function and therefore is only applicable if the associated user need is selected. The PRL indicates which of the items are mandatory, conditional, or optional. In most NTCIP 12xx series standards, the PRL indicates which user needs are considered mandatory; however this document omits this information because it is not within the scope of this document to define which features should be supported by specific device types (i.e., a feature that might be mandatory for one device type might not be applicable to another device type). Device-specific standards should indicate which of the user needs identified in this standard are mandatory, optional, or conditional and should either refer to this table for details about their traceability to requirements or replicate the rows as shown in this table. A device-specific PRL can be used by procurement personnel to specify the desired features of an ITS field device or can be used by a manufacturer to document the features supported by their implementation.

Operational Environment Requirements – These are requirements related to the operational environment user needs.

Data Exchange Requirements – These are requirements related to the features that can be realized through a data exchange.

Supplemental Requirements – These are additional requirements derived from the Concept of Operations that do not fall into one of the above two categories.

This section is intended for all readers of the document, including:

Transportation operations managers

Transportation operations personnel

Transportation engineers

System integrators

Device manufacturers

These readers will find this section useful to understand the details of what this document requires of the ITS field device and how the user needs defined in Section 2 trace to these user needs.

The Functional Requirements Section defines the formal requirements that are intended to fulfill defined user needs (e.g., those defined in Section 2). This is achieved through the development of the Protocol Requirements List (PRL), which traces each user need to one or more requirements defined in this section. The details of each requirement are then presented following the PRL. The functional requirements are presented in three broad categories as follows:

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 upon the architectural needs identified in the Concept of Operations.

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 the Concept of Operations.

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 messages a VMS is required to support or what the message shall be on a blank-out sign).

Some of the requirements defined in this section fulfill user needs defined in other documents and do not appear in the PRL.

This document only addresses aspects of the ITS Application Entity and the Management Entity of the ITS station reference architecture (ISO 21217). It does not define the Facilities, TransNet, or Access Layers or the Security Entity. This document is written with the assumption that the ITS Application Entity will rely upon an NTCIP 2301 definition of the Facilities Layer and Security Entity.

The PRL, provided in Sections 3.3.3, maps the user needs defined in Section 2 to requirements defined in Section 3. The table can be used by:

A user or specification writer to indicate which requirements are to be implemented in a project-specific implementation.

The protocol implementer, as a checklist to reduce the risk of failure to conform to this document.

The supplier and user, as a detailed indication of the capabilities of the implementation.

The user, as a basis for initially checking the potential interoperability with another implementation.

The following notations and symbols are used to indicate status and conditional status in the PRL within all NTCIP standards. Not all of these notations and symbols may be used within this document.

The symbols in Table 1 are used to indicate status.

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 must 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."

The predicate notations in Table 2 may be used.

The <predicate>: 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 <predicate>:: 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 completed. 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.

The predicates used in his document map to the sections in Table 3.

The support column can be used by a procurement specification to identify the required features for the given agency (procurement) specification 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 4).

In the "project requirements" column, each response shall be selected from the indicated set of responses (for example: Yes / No / NA). Additional requirements may be placed in the "Additional Project Requirements" column, which may reference an attachment.

If a conditional requirement is inapplicable, use the Not Applicable (NA) choice. If a mandatory requirement is not satisfied, exception information must 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 3.3.1.1 above), the response shall address each element of the requirement; e.g., for the requirement "mo," the possible compliant responses are "yy" or "yn."

A procurement specification can allow for flexibility in a deliverable by leaving the selection in the Project Requirement column blank for a given row.

To claim "Conformance" to this document, the vendor must minimally satisfy the mandatory requirements as identified in the tables that compose this PRL.

The reader and user of this document is advised that 'conformance' should not be confused with 'compliance' to a specification. This document is as broad as possible to allow a very simple devices to be 'conformant'. A specification will need to identify the requirements of a particular project and needs to require the support of those requirements. A specification writer is advised to match the requirements of a project with the corresponding standardized requirements defined in this document to achieve interoperability. This means that functions and requirements defined as 'optional' might need to be selected in a specification (in effect made 'mandatory' for the project-specific specification).

A conformant device may offer additional features, if they are conformant with the requirements of his document and the standards it references (e.g., NTCIP 1201, NTCIP 2301, and NTCIP 8004). For example, a device may support data that has not been defined by his document; however, when exchanged via one of the NTCIP 2301 protocols, the data must be properly registered with a valid OBJECT IDENTIFIER under the Global ISO Naming Tree.

Off-the-shelf interoperability and interchangeability can only be obtained through well documented features broadly supported by the industry. Designing a system that uses features not defined in a standard or not typically deployed in combination with one another will inhibit the goals of interoperability and interchangeability, especially if the documentation of these features is not available for distribution to system integrators. The 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 involved with using such features.

In addition to the conformance column and the support/project requirement column, which were discussed in Section 3.3.1, the additional columns in the PRL table are the user needs columns, requirements columns and the additional project requirements column.

The user needs are defined within Section 2 and the PRL is based upon the user need sections within that Section. The section number and user need name are indicated within these columns.

The requirements column is used to trace the indicated user need to its associated requirements using a reference to the clause along with the title of that clause. If no document is listed in the reference, the reference is to a section within this document. References to ISO documents refer to "features", which are defined as a group of related requirements. Some of the ISO features have optional requirements; these can be selected through the ISO PRL, which is available at https://standards.iso.org/iso/26048-1/ed-1/en/Concise_PICS.docx.

The "Additional Project Requirements" column may (and should) be used by a procurement specification to provide additional notes and requirements for the product to be procured or may be used by an implementer to provide any additional details about the implementation. In some cases, default text already exists in this field, 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.

The contents of the Protocol Requirements List is limited to those object-types included in this standard for which systems engineering content was previously defined. It does not cover the scope of all object-types included in this document.

The following requirements were either explicitly or implicitly contained in previous versions of NTCIP and are listed here to support a level of backwards compatibility during migration to the updated NTCIP documents that are based on SNMPv3. Specifically, the intent of these requirements is to provide a way for an SNMPv3 manager conforming to this document to interface with a proxy agent acting as a translator for a field device, as discussed in Section 1.

Requirements for making requests follow.

A management station shall be able to retrieve any set of data from the device at any time.

A management station shall be able to deliver data (e.g., configuration data, commands, etc.) to the device at any time.

Other requirements can place restrictions on how the device may respond under certain scenarios.

A management station shall be able to dynamically discover what data and data instances are supported by the device.

A management station shall be able to retrieve any set of sequential data from the device at any time.

While a management station can issue a bulk request to a proxy agent, SNMPv1 did not support bulk requests. It is the responsibility of the proxy agent to transform any such bulk request into a series of requests to the field device as needed to fulfill the incoming request.

An implementation that supports both the objects contained within this standard and the defined superseding objects (e.g., as contained in ISO 26048-1) shall ensure that the underlying data is synchronized between two representations. For example, setting globalTime (5.5.1) shall also affect the value of fdClockUtcTime and fdClockUtcDate. 

Requirements for managing access to the information stored within the proxy agent are provided in the following subsections.

Upon request from an authorized management station, the field device shall provide the number of community names supported by the device.

Upon request from an authorized management station, the field device shall provide the current administrator community name.

Upon request from an authorized management station, the field device shall configure the administrator community name with the specified value.

Upon request from an authorized management station, the field device shall provide the current data access configuration for the specified community of users.

Upon request from an authorized management station, the field device shall configure access settings for an access level, including the community names and access rights.

Requirements for managing access to the information stored within the proxy agent are provided in the following subsections.

The specification will identify the number of community names that the field device shall support. If the specification does not define the number of community names, the field device shall support at least one community name in addition to the administrator access level.

Upon request from a management station, the device shall return the number of device components for which information is available.

Upon request from a management station, the device shall return identification information for the specified module contained in the device, including:

an indication of the type of device

the manufacturer of the module

the model number or firmware reference of the module

the version of the module

an indication of whether it is a software or hardware module

Upon request from a management station, the device shall return a code that only changes when changes are made to the controller configuration. This requirement allows the management station to verify the version of the database stored in the field device.

Upon request from a management station, the device shall return the NTCIP standards that it supports.

Upon request from a management station, the device shall return the text-based (system) name and location of the device.

Upon request from a management station, the device shall configure the text-based (system) name and location of the device.

Upon request from a management station, the device shall return the list of object instances considered in the current device configuration identifier starting with object instances associated with object types defined in NTCIP standards and followed by any object instances associated with manufacturer-specific object types.

There are no supplemental requirements defined for the basic device.

Requirements for managing the sign controller's scheduling feature are provided in the following subsections.

Upon request from a management station, the field device shall return the maximum number of schedules, day plans, and day plan events supported by the field device.

Upon request from a management station, the field device shall store one logical entry in the day plan selection table, consisting of the month, day of month, day of week settings, and day plan to be selected when the time parameters are met.

Upon request from a management station, the field device shall store an entry in the day plan table, which points to actions to be executed when the day plan is active and the time of day has been reached (and no other actions, such as manual control overriding time-based scheduling, inhibits the execution of the action).

Upon request from a management station, the field device shall return a specified entry from the time-based scheduler, which is used to select a day plan.

Upon request from a management station, the field device shall return a specified entry from the day plan table, which identifies the action to be executed at a specified time within a day plan.

Upon request from a management station, the field device shall return the time-based scheduler entry that is currently selected for use.

A schedule entry indicated to be active does not mean that this schedule entry is actually active (because other actions within the device, such as manual control overriding time-based scheduling, might override the activation and use of the selected day plan).

Upon request from a management station, the field device shall return the day plan within the scheduler that is currently selected for use.

A day plan indicated to be active does not mean that this plan is actually controlling the device because other actions within the field device (e.g., manual control) can override the day plan.

Supplemental requirements for defining a time-based schedule are provided in the following subsections.

The device shall support the number of day selection patterns as specified in the specification. If the specification does not define the number of day selection patterns, the device shall support at least one day selection pattern.

A day selection pattern is a mechanism that selects a day plan to run based on the given day matching a pattern for months, days of week, and dates of month.

The device shall support the number of day plans as defined by the specification. If the specification does not define the number of day plans, the device shall support at least one day plan.

The device shall support the number of day plan events for each supported day plan as defined in the specification. If the specification does not define the number of day plan events, the device shall support at least two day plan events per day plan.

Upon request from a management station, the device shall return the capabilities of the event logging service, including the number of classes, number of event types, and number of events that can be supported by the device.

Upon request from a management station, the device shall configure the event logging service as requested, including configuration of the event classes and event types to log.

Upon request from a management station, the device shall configure the event logging service as requested, including configuration of the event classes and event types to log.

Upon request from a management station, the device shall return the current configuration of the event logging service, including the classes and types of events that are currently configured.