Comm Links

Select View ➔ Maintenance ➔ Comm Links menu item

A comm link is a network connection to an external device or system. IRIS is capable of supporting thousands of simultaneous comm links.

URI

The URI includes a DNS host name or network IP address, and port number, using the standard host:port convention. It can also contain an optional scheme prefix, which can be either udp://, tcp:// or modem://. If present, the scheme will override the default scheme for the selected protocol. For example, to use the Pelco-D protocol over TCP (instead of the default UDP), prepend tcp:// to the URI.

Poll Enabled

Polling can be disabled using this value.

Comm Config

Select View ➔ Maintenance ➔ Comm Config menu item

Modem

The modem flag indicates the connection uses a dial-up or cell modem.

Poll Period

Poll period determines how frequently controllers on a comm link are polled. It can range from 5 seconds to 24 hours.

Long Poll Period

This period is for less frequently performed polling operations, determined by the protocol. For modem links with restricted bandwidth, it may be useful if both poll periods use the same (long) value, to reduce costs.

Timeout

After a poll, if a response is not received before the timeout expires, the communicaton will fail. For each poll, 2 retries will happen before the operation is aborted.

Idle Disconnect

When this value is greater than zero, the comm link will be disconnected after a period of inactivity. This can reduce charges for modem links.

No Response Disconnect

When this value is greater than zero, the comm link will be disconnected after no response is received from a poll for the specified time.

Protocols

Protocol determines what type of device or system is on the other end of the comm link. Each protocol supports specific device types. Some protocols support multi-drop addressing, with multiple controllers per comm link.

Axis PTZ

The axisptz protocol can be used for PTZ control of Axis cameras. The default scheme is http. Multi-drop is not supported. One camera can be associated with each controller, using IO pin 1.

Canoga

The canoga protocol can collect vehicle detection data, with vehicle logging instead of binned data. The default scheme is tcp. Multi-drop is supported with drops 1 - 255. Up to 4 detectors can be associated with each controller, using IO pins 1 - 4.

CBW

The cbw protocol can be used for beacons, using a Control-By-Web controller. The default scheme is http. Multi-drop is not supported. Up to 8 beacons can be associated with each controller, using IO pins 1 - 8.

Cohu

The cohu protocol can be used for PTZ control of Cohu cameras. The default scheme is tcp. Multi-drop is supported with drops 1 - 223. One camera can be associated with each controller, using IO pin 1.

Din-Relay

The dinrelay protocol can be used for changeable LCS or beacons, using a DLI Din-Relay. The default scheme is http. Multi-drop is not supported. Up to 8 indications can be associated with each controller, using IO pins 1 - 8.

DMS-XML

DMS-XML is a protocol for legacy DMS control systems. The default scheme is tcp, with multi-drop (0-65535).

DR-500

The Houston Radar DR-500 doppler radar can be used to collect speed data only. The default scheme is tcp. Multi-drop is not supported. Only one detector can be associated with each controller, using IO pin 1.

DXM

The Banner Engineering DXM magnetometer can detect vehicle presence for parking area monitoring. The default scheme is tcp. Multi-drop is not supported. Up to 76 detectors can be associated with each controller, using IO pins 11 - 86.

E6

The e6 protocol can be used for collecting data from Transcore tag readers. The default scheme is udp. Multi-drop is not supported. One tag reader can be associated with each controller, using IO pin 1.

G4

The G4 protocol can collect vehicle detection data, including vehicle counts, occupancy, speed and vehicle classification. The default scheme is tcp. Multi-drop is supported with drops 0 - 65535. Up to 12 detectors can be associated with each controller, using IO pins 1 - 12.

Inc-Feed

The incfeed protocol can be used to interface IRIS with an external system that generates incidents. Periodically, IRIS will poll the URI (using http) for incidents.

Incident Feed Format

The external system should respond with an ASCII text file, with one line per active incident.

Each line should contain 7 fields, separated by comma characters , and terminated with a single newline character \n (ASCII 0x0A). The fields are:

1. incident ID
2. type: CRASH, STALL, ROADWORK or HAZARD
3. incident detail: may be blank, or one of the incident detail names
4. latitude
5. longitude
6. camera ID: may be blank, or the ID of a camera to view the incident
7. direction: NB, SB, EB or WB

Latitude and longitude define coördinates using the WGS 84 datum.

Infinova

The infinova protocol can be used for PTZ control of Infinova cameras. The default scheme is tcp. Multi-drop is supported with drops 1 - 254. One camera can be associated with each controller, using IO pin 1.

Manchester

The manchester protocol can be used for PTZ control of some older cameras. The default scheme is udp. Multi-drop is supported with drops 1 - 1024. One camera can be associated with each controller, using IO pin 1.

MnDOT-170

170 style controllers running the MnDOT 170 firmware can support several types of devices:

There are two versions of the protocol supported:

MonStream

The monstream protocol can be used for switching of monstream video monitors. The default scheme is udp. Multi-drop is not supported. Up to 16 video monitors can be associated with each controller, using IO pins 1 - 16.

Msg-Feed

The msgfeed protocol can be used to interface with an external system that generates DMS messages. Periodically, IRIS will poll the URI (using http) for DMS messages.

Msg-Feed Format

The external system should respond with an ASCII text file, with one line per message to be deployed.

Each line must contain 3 fields, separated by tab characters \t (ASCII 0x09), and terminated with a single newline character \n (ASCII 0x0A). The fields are DMS name, MULTI string, and expiration time. The DMS name must exactly match one of the DMS as identified by IRIS. The MULTI string specifies a message to display on the sign, using the MULTI markup language. The expiration time field indicates the date and time that the message should expire, in RFC 3339 format, with full-date and full-time separated by a space instead of T.

V66E37	CRASH[nl]5 MILES AHEAD[nl]LEFT LANE CLOSED	2019-10-02 11:37:00-05:00

Msg-Feed Action Plan

An action plan is required to associate a DMS action with the feed. The DMS action must have a quick message with a feed action tag. So, if the message feed is on a Comm Link called LFEED, then the quick message MULTI string must be [feedLFEED]. Also, the action plan must be active and deployed. This requirement allows only administrator-approved DMS to be controlled by the message feed.

Msg-Feed Text

All messages used by the feed must be defined in the DMS message library. This requirement allows only administrator-approved messages to be deployed by the message feed. In some circumstances, it may be appropriate to disable this checking. For example, if the message feed host is fully trusted and there is no possibility of man-in-the-middle attacks between IRIS and the feed host. In this case the msg_feed_verify system attribute can be set to false to disable this check.

Msg-Feed Beacons

To activate DMS beacons through a message feed, configure 2 message feeds. One is for DMS containing messages with activated beacons and the other for messages with deactivated beacons. There is no way to control which message feed is executed first, so each message feed must list each DMS and at least one of the message feeds must contain a blank MULTI for each DMS.

NTCIP

National Transportation Communications for Intelligent transportation system Protocol is supported for several different device types:

• DMS — NTCIP 1203
• LCS, using DMS for lane control
• RWIS — NTCIP 1204
• vehicle detection — NTCIP 1202
• GPS — NTCIP 1204

There are three supported variants:

Org815

The org815 protocol can be used to collect rwis data from an Org-815 precipitation sensor. The default scheme is tcp. Multi-drop is not supported. One device can be associated with each controller, using IO pin 1.

Pelco D

The pelcod protocol can be used for PTZ control of Pelco cameras. The default scheme is udp. Multi-drop is supported with drops 1 - 254. One camera can be associated with each controller, using IO pin 1.

Pelco P

The pelcop protocol can be used for camera keyboard control from Pelco keyboards. The default scheme is tcp. Multi-drop is not supported. No devices need to be associated with the keyboard controller.

RedLion

The redlion protocol can be used for GPS data from RedLion modems. The default scheme is tcp. Multi-drop is not supported. One GPS modem can be associated with each controller, using IO pin 1.

SierraGX

The sierragx protocol can be used for GPS data from SierraGX modems. The default scheme is tcp. Multi-drop is not supported. One GPS modem can be associated with each controller, using IO pin 1.

SmartSensor

The SmartSensor (SS105) and SmartSensor HD (SS125) protocols can collect vehicle detection data, including vehicle counts, occupancy, speed and vehicle classification. The default scheme is tcp for both.

STC

The stc protocol can be used for gate arm control for Smart Touch gate arms. The default scheme is tcp. Multi-drop is supported with drops 1 - 99. One gate arm can be associated with each controller, using IO pin 1.

Streambed

The streambed protocol is for flow stream configuration with a streambed server. The default scheme is tcp. Multi-drop is not supported. Up to 150 flow streams can be associated with each controller, using IO pins.

Vicon

The vicon protocol can be used for PTZ control of Vicon cameras. The default scheme is udp. Multi-drop is supported with drops 1 - 254. One camera can be associated with each controller, using IO pin 1.