NTCIP is a suite of protocols that allow ITS field devices from multiple manufacturers to be controlled from a single Central system. One element of NTCIP that allows manufacturers and specifying agencies to clearly and precisely communicate the features that are supported by a field device is a Management Information Base, or MIB. A MIB is a text file that lists the objects and their supported ranges. It includes the functionality supported by the objects and is written so that it can be read by a Central system. Each NTCIP standard has a MIB that includes the mandatory and optional objects that are included in a particular standard. However, there are instances where a custom MIB is warranted.
Why create a custom MIB?
When a manufacturer has developed a new type of device or added a unique feature, one that is not standard, they often create a custom MIB. A custom MIB will accurately address the object and form the structure that supports the device’s feature. Many times, these MIBs include functionality that sets a device apart from the competition, or is a newly developed feature that is not able to be managed with a standard MIB.
Conversely, if an organization wanted to purchase a device that must include a particular non-standard feature, a custom MIB would allow them to clearly specify the functional requirements. By supplying a custom object to manufacturers, the company can communicate the exact unique functionality needed, rather than allow each manufacturer to create their own custom MIB.
A custom MIB can be written to increase the functionality provided by an existing standard MIB. In this case, the standard objects are not modified; the new custom MIB is written with objects that include the existing functionality as well as the expanded functionality. A custom MIB can also be created without reference to an existing NTCIP standard. This is typically the case when a device is not currently covered by NTCIP.
Formatting a MIB
MIBs are formatted in ASN.1 notation, which is a standard notation that describes the rules and structures of the MIB. The MIB provides information about the individual objects themselves and the object’s location within ISO Global Naming Tree. As an example, the standard dmsSignHeight object from the MIB for NTCIP 1203 – DMS is shown below.
dmsSignHeight OBJECT-TYPE
SYNTAX INTEGER (0—65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION “Indicates the sign height in millimeters including the border (dmsVerticalBorder).
<Unit>millimeter
<Object Identifier> 1.3.6.1.4.1.1206.4.2.3.1.3”
::= {dmsSignCfg 3}
This object allows the Central system to query a sign to determine its physical height. The SYNTAX field, along with the DESCRIPTION field, indicates that the heights available for selection range from 0 to 65.535 meters. The ACCESS field shows that the Central system can only retrieve this object; if this were an object that the Central system could change, the ACCESS field would be set to “read-write”.The last line of the example shows the object’s location within the ISO Global Naming Tree. All of the objects in NTCIP are organized in a hierarchical fashion similar to a tree, where the ISO node is the root of the tree, to which nodes are attached like branches on a tree. Each object is then positioned like a leaf on the tree. In the example, dmsSignHeight is the third leaf (the “3” at the end of the Object Identifier) of node dmsSignCfg (the “1” just before the “3”).Custom objects are organized on the ISO Global Naming Tree under the creating organization’s assigned identification number. For example, the National Electrical Manufacturer’s Association (NEMA) identifier is 1206, and the Delcan Technologies identifier is 26, so the node under which Delcan Technologies custom objects are found is 1.3.6.1.4.1.1206.26.
Creating a Custom MIB
From a timing perspective, a custom MIB can be developed in a few days, or a few weeks, depending upon the scope of the added features. The number and size of features is the primary driver of that determination, as a larger, more complex project would require substantially more work and coding than a smaller project.If you have a project that would benefit from the creation of custom objects, Delcan Technologies can offer a superior level of expertise in this area. Delcan Technologies, a Parsons Company, is a world leader in design and implementation of ITS solutions. We partner with our clients as consultants, developers, and contractors to support them at all levels of a project. For more information on how we can help, contact us here.
The Delcan Technologies embedded cards can be used either to perform as the controller in an OEM ITS device or to upgrade any existing ITS device to NTCIP conformance. They connect sensors or hardware to the device using analog or digital inputs. Data and proprietary protocols are converted to NTCIP and sent to the central system.
Testing a Variable Message Sign (VMS) for NTCIP compliance is a way for organizations to confirm the communication and functional elements of the sign are working properly. Section 1203 of the NTCIP standard focuses on dynamic message signs and is the data dictionary that defines sign functionality.
A successful test should confirm that information is transferred from the central system to the sign and that the sign returns a response. Once the information reaches the sign, the test should evaluate the sign’s action from an operational perspective. Common items that are reviewed during the test include:
- Does the sign perform the action properly?
- Did the message display properly?
- Is the sign using the correct font?
- Is the text centered as directed?
How are tests performed?
Typically, a sample sign is set-up in a shop environment, or a manufacturer’s facility, along with test equipment that simulates different test scenarios. Testing software (such as Device Tester) records the results of each test administered as it relates to features, functionality, and formatting. The number of scenarios to be tested is substantial and can take up to a week to be fully tested against the standard.
Why test?
Testing variable message signs is critical to ensure NTCIP compliance. Thorough testing gives a manufacturer the confidence and validation needed to guarantee compliance with the NTCIP standard. From the DOT perspective, valid VMS testing decreases the likelihood of major issues when the system introduced into an ITS environment. When all parties are working from the same NTCIP standard, the deployment process is much smoother and fewer errors are detected.
NTCIP 1203
NTCIP 1203, the library that relates to dynamic message signs, has undergone three major revisions, with each version adding more features and functionality.
- Version 1, the initial standard, included the basic functionality to transfer a message to a sign, display the message on the actual sign and to receive information back from the sign. The standard included the brightness level of the sign, the adjustment of these levels, and the ability to set fonts.
- Version 2 added some additional functionality, but primarily dealt with graphics and color. Graphics could be displayed on the sign up to its full size and the number of colors from which to choose was in the thousands. It also allows for centering of text and image display and the ability to create “mini signs” within the main sign space.
- Version 3 added the ability to add formal test procedures. With more than 300 pages of formal test procedures, users can make their selection based on the features that need to be tested.
There is compatibility among versions of NTCIP between VMS signs. A Version 2 sign can successfully receive messages from a Version 1 control center; however, the combination would limit the functionality and features to whichever version is earlier. Upgrading to the newest version is ideal, but not required.
Delcan Technologies can help
Delcan Technologies, a Parsons company, is a world leader in the design and implementation of ITS systems and is involved in all stages of deployment as consultant, system developer and contractor. We provide support for manufacturers at any level. For more information on how we can assist you in your efforts, contact us here.
NTCIP is a widely deployed and accepted protocol for transportation communications within the United States and abroad. As the range of NTCIP continues to expand, protecting and securing transportation networks powered by NTCIP is becoming more important.
Why secure NTCIP?
There are multiple threats that every computer network faces. Automated programs and viruses frequently seek any system that is open to attack, regardless of whether it is a DOT system or not. These are not necessarily targeted attacks; they are simply individuals seeking to wreak havoc. Attacks on NTCIP based networks can also be premeditated. When a DOT system is compromised, and someone else gains control, the system can be shut down, sign messages can be manipulated, and driver safety is put at risk.
Four categories of security
The National Electrical Manufacturer Association (NEMA) Cyber Security Group has been tasked with exploring security concerns as they relate to ITS products. The group, headed by Delcan Technologies team member Russ Brookshire, is addressing standards for devices and the enclosures in which they are housed. Their goal is to establish prevention and mitigation techniques as well as to develop a method to rate security performance.
As NEMA works to identify all possible ways in which a system can be compromised, they are also looking at what steps can be taken to prevent those breaches in security. The standard is being created around four levels of security:
Physical Security
Physical security looks at the actual device to determine how well it is secured. Is the cabinet locked? Who has possession of the keys and is there a formal process when someone with key access is terminated? We assume that these safeguards are in place, but in order to create a secure system, these formal processes must be followed in every instance.
Local Access Security
Local access security addresses the field procedure once a person opens the sign cabinet. Is there immediate access or is there local password control? Is that level of security able to be bypassed?
Communication Security
Communication security deals with the method of information transfer. NTCIP offers basic security features, so it’s important to look for additional ways to secure the system. Are you passing data across a cellular network? Is it part of a public network or is it a private network? Is there a way to limit access?
Central System Security
Central system security includes the security of the actual application, which, among other things, controls the signs, monitors the cameras and reports traffic speed. This level deals with controlling access to the server and client computers, and ensuring that any security information kept on these computers is encrypted. In addition, this level of security addresses the system that controls the network of computers, and is normally handled by the IT department.
Is security a concern?
ITS security concerns are valid, but incidents are not a frequent occurrence. Occasionally there are instances of a breach, but security across any system is paramount. It’s important to have full control when you need to communicate or gather valuable information, whether that’s on an ordinary day or in a state of emergency.
In recent years, there has been a substantial increase in NTCIP activity in South America. In 2010, Brazil began the widespread use of NTCIP, and its adoption has continued to grow at an increasing rate. For the most part, specifying and using NTCIP in South America is the same as North America. There is very little distinction between field devices or dynamic message signs. There are, however, fundamental differences with traffic controllers and multi-faced signs.
Dynamic message signs in South America
There are a variety of NTCIP VMS signs that can be deployed in South America. Given the standard commonly used in South America, the Parsons team is able to modify the signs to support NTCIP. The software effort needed to communicate with an NTCIP sign requires a high level of expertise, but is less intensive than that of a traffic intersection controller.
Additionally, NTCIP is typically built around the assumption of a single sign face. Some European style signs have a high-density graphic area with adjacent low-density lines for text. The concept of different densities in a single sign is not addressed by current NTCIP standards, but that is an obstacle that can be overcome.
NTCIP traffic controllers in South America
There is a distinct level of complexity inside a traffic controller. Their functionality is incredibly intricate, especially with some of the newer features available. Most of the confusion in signal controllers revolves around the type of model being used. Phase-based and stage-based models are two fundamentally different ways of passing traffic through an intersection. Every intersection in the US is a phase-based intersection, which allows for a variable signal cycle. South America uses European-style stage-based control, a fixed assignment of red, yellow and green indicators.
The obstacle within a bid arises when an NTCIP intersection controller is specified, but the overall system is stage-based. This mixing of standards often causes confusion if the issue is not addressed early in the bid process.
What’s on the horizon?
Many bids from South America are continuing to specify NTCIP, but we’re seeing an increased amount of confusion because there is a disconnect between devices that are compliant and implementation methods that are not. We will continue to see changes in the market as it becomes more dependent on NTCIP.
Success will depend heavily on policymakers and manufacturers working together and communicating effectively to ensure it is implemented in a way that everyone understands. This includes the move from phase-based to stage-based control, custom MIBS for stage-based equipment, and how to approach multi-faceted signs within NTCIP standards.
Delcan Technologies can help by providing NTCIP testing and consulting services to ensure conformance and help your project or bid run more smoothly.
NTCIP is frequently used to manage and control traffic signal controllers. NTCIP 1202 is the section of the standard that addresses traffic signal controllers, which includes the standard objects for most of the general settings. Some examples of standard objects include how an intersection works, setting times for green, yellow, red and the order that the movements progress around the intersection.
Managing traffic patterns
NTCIP 1202 allows the user to control and direct traffic patterns using traffic signal controllers. In general, all traffic signal controllers respond to pattern commands, which is the primary method of changing or controlling what’s happening at a traffic intersection.
Pattern commands are used to create time-of-day traffic patterns that occur on a regular basis. In the morning, most commuters are headed to work, so traffic is heavy. Mid-morning is a more general, non-optimized pattern. Lunchtime can be heavier, mid-afternoon returns to a general pattern and then finally, the rush hour pattern, where signal are optimized for traffic flowing out of an area and headed home.
The central system can command a pattern to a zone and all traffic controllers will run the same pattern until told to do something differently. It can also generate a “status and health” report, which pulls back the default standard timing parameters and displays the results on a map in a traffic center, so authorities can monitor the activity around the city. Standard NTCIP also has the ability to alert the user to issues such as electrical problems, when a controller is in default flash mode or when a cabinet door is open, for example.
Manufacturer add-ons
Manufacturers are not permitted to change, expand or modify NTCIP 1202, but there are some placeholders available in the 1202 MIB that allow manufacturers to specify or add commands. In some commands, there may be multiple ways for the device to perform, but there is also an option for “other” in the standard object. When manufacturers have a custom object for their device, they create their own MIB, which specifies what happens in the traffic controller when you set the standard object to “other”.
Also, some manufacturers have proprietary objects that control how devices behave in situations where the standard objects do not define the task or perform special functions based on what’s happening in the intersection.
Future Updates
Version 2 is the current version of NTCIP 1202, but a new version is in development. The updated version will add coverage of several features that most traffic controller manufacturers already have but are not included in the original specification. It will allow central systems to perform more of the standard tasks and do it consistently across multiple manufacturers. The challenge will be gaining consensus among manufacturers as to the generic defaults. The process is expected to begin in 2016 but may take longer than a year to have it completed and approved.
Device Tester is a software product, developed by Delcan Technologies, that tests field devices and ITS central systems to ensure their functionality is consistent with the NTCIP standards. NTCIP compatibility is required by the United States Department of Transportation for any project that receives federal highway dollars, so it’s important to ensure compliance with the NTCIP standard. Let’s take a look at the features of Device Tester.
MIB-Based Testing
Device Tester uses a Management Information Base, or MIB, to verify how a device responds to an object and compares the results against established NTCIP compliance standards. These MIBs include a wide range of values, a description of the data, whether the object is read-only or read/write…essentially everything communicable through the device.
After loading a MIB into Device Tester, the user is able to communicate with the device in order to perform tests. These tests measure how the device responds to every object in the MIB. Device Tester maintains a log of each test and the given responses.
Standard & Custom MIBs
Device Tester includes a number of pre-loaded, standard MIBs and can read both standard and custom MIBs. When manufacturers sell a device, it must be designed to communicate with the standard MIBs. Standard MIBs address global objects, such as time of day settings, as well as device specific objects, such as sign status for variable message signs. Manufacturers can add additional objects and features that separate their device from a competitor. These objects are defined in a custom MIB created by the manufacturer, which must be written in the standard international format ASN.1 (Abstract Syntax Notation One).
Scripting Ability
In addition to the automated tests run by loading and scanning a MIB, Device Tester also includes the ability to create and run test scripts. This feature allows you to build a custom script that automates a specific test procedure. With custom scripting, manufacturers and developers can perform unique tests on a device to ensure it passes a specific test.
Device Tester comes pre-installed with an initial set of scripts. If needed, Delcan Technologies has a team of engineers that have the ability to create custom scripts to test custom objects. The Delcan Technologies team is able to provide additional services to help generate the custom test procedures, run the test and verify the results.
The National Transportation Communications for Intelligent Transportation System (ITS) Protocol, or NTCIP, is a protocol that allows traffic devices to communicate with each other. Prior to the development of NTCIP, ITS devices and systems from different manufacturers were unable to communicate without a costly and time-consuming integration effort. Devices that support NTCIP are considered NTCIP “conformant”, which is a requirement in many bids or RFPs. Often times, the device must also meet the specific requirements, making the device “compliant.” Let’s explore the differences and what it means to be conformant and compliant.
Conformance vs. Compliance
It’s important to understand that conformance and compliance are not interchangeable terms. Whether a device is conformant or non-conformant is determined by how it relates to the NCTIP standard. Conforming to the NTCIP protocol requires meeting a list of minimum standards.
Compliance relates to the specifications within the bid or the RFP. Typically included in a bid or an RFP is a detailed list of NTCIP functions that the given device should have the ability to perform. The device must be able to support all of the requirements in order for it to claim compliance.
It is possible for a device to be NTCIP conformant and not be compliant with an RFP or bid. For example, a sign may have the ability to store 50 messages and 50 events. It meets the list of mandatory NTCIP requirements and is conformant to the NTCIP standard. However, if a bid specifies 250 messages and 250 events, the device is not compliant with the bid.
PRL
The number and scope of options within NTCIP is virtually limitless. The PRL, or Protocol Requirements List, is a means of standardizing the requested options. Essentially it’s a checklist within a standard. The objective of the PRL is to clarify the list of features that are required by the specifying organization. When creating a bid, an organization can use the PRL to specify which features they want the device to support. Vendors can then consult the standard PRL to determine if their device is compliant with the bid. The PRL lets both the specifying organization and vendor agree on what compliance means.
PICS
An additional method to communicate compliance is through a Protocol Information Conformance Statement, or PICS. PICS are created by the manufacturer and are a checklist that indicates which options are supported by a particular device. It clearly lists the functionality of the product using the PRL and can be used to verify conformance to the standard and compliance with the specifications.
For more information on NTCIP conformance and compliance, PRLs and PICS, visit our previous posts, What Is NTCIP?, NTCIP Protocol Requirements, and Creating a Better NTCIP Specification With the PRL.
The NTCIP protocol is an industry wide standard data communications protocol, designed to facilitate interoperability and interchangeability between computers and electronic traffic control equipment from different manufacturers.
Each layer of the protocol provides an increasing level of detail as to how information should be transferred and received. It explains the logical progression of the process, what to do with the information and in what order to do it.
5 Levels of NTCIP Protocol
NTCIP defines both the method of transferring information and also the functionality of the field device, answering questions such as: what communications hardware is to be supported? How is the data to be packetized, sent, and verified? What optional functions must the field device support, such as sign display colors, camera labels, and weather station sensors?
There are five defined levels that makeup NTCIP. These include: information level, application level, transport level, subnetwork level, and plant level.
- Information Level defines the meaning of the data and represents the functionality of the system.
- Application Level defines the rules for exchanging data. It is responsible for the sequence of statements in order to form a complete thought or sentence.
- Transport Level defines the rules and procedures for exchanging the application data, including any necessary routing, assembly or reassembly of a message and network management functions.
- Subnetwork Level defines the rules and procedures for exchanging data between two devices over a chosen communications media.
- Plant Level The Plant Level is shown in the NTCIP Framework only as a means of providing a point of reference to those learning about NTCIP. It includes the communications infrastructure over which NTCIP communications standards are to be used.
NTCIP Resources
Mastering NTCIP takes effort and there are not a wide range of classes or books to choose from when it comes to learning the protocol. Having an understanding of programming languages and the basics of networking are the best places to start.
There are some online resources you can leverage to gain a working knowledge of NTCIP. These include the NTCIP 9001 “Guide” for detailed deployment and NTCIP procurement information, the NTCIP Forums, which provide a channel for both technical and non-technical people to discuss the NTCIP and the Library Table, which has links to the status information, drafts, and jointly approved standards.
All NTCIP standards are published on the NTCIP website and webinars that define both the standard itself, testing to the standard, and individual standards for specific devices are often available.
The National Transportation Communications for Intelligent Transportation System Protocol (NTCIP) is a U.S. standard that streamlines communication between central systems and devices. NTCIP-conforming devices have now been installed throughout the world because abiding by the requirements of NTCIP ensures interoperable and interchangeable communication.
When it comes to creating RFP’s, bids, or project specifications, simply stating that a device be NTCIP-conformant is not enough. When creating specifications that call for NTCIP, the requirements need to be as specific as possible. So, how do you ensure that you have a good specification?
Specific Requests, Specific Results
The Protocol Requirements List (PRL) is a vital tool when creating an NTCIP specification. The PRL lists and defines all the features and variations that can be specified with NTCIP. This includes all of the mandatory and optional functional features.
General requests within your specification lead to wasted time, money, and result in unused equipment. Using the PRL to create a specification will help ensure all your projects and communications abide by the NTCIP requirements you need. To write a good specification, review the PRL, and select the items that you need your system to support.
Both specifying authorities and manufacturers benefit from using PRLs. Specifying authorities benefit because choosing specific items on the PRL increases the accuracy of the bids received. Manufacturers benefit because they indicate functional requirements supported by their devices. Their list is referred to as a protocol implementation conformance statement (PICS).
For more information on PRLs, review our post titled “NTCIP Protocol Requirements Lists (PRL) – An Overview” at http://delcantechnologies.com/ntcip-protocol-requirements-lists-prl-an-overview.
We’re Here to Help
Delcan Technologies employs a full team of NTCIP experts to guide any entity, including specifying authorities and device manufacturers, through the process of design, development, and testing. This ensures that all elements of the Advanced Traffic Management System are in full conformance with industry standards.
You can also visit the US Department of Transportation’s website to view their resource at http://www.pcb.its.dot.gov/stds_training.aspx/.
