Introduction
ICD-001 is a network communication protocol based on XML. The protocol is used over standard TCP/IP client-server connections.
The ICD-001 documentation describes the protocol in detail, including message structure, message framing and all the message types.
For customers and integrators intending to use ICD-001, the documents assume a reasonable working knowledge of network communications, XML and XSD. They are targeted at technical teams, typically with software development skills, who are integrating the output from Witness into external systems.
This section covers the configuration of the plugin within Witness. The configuration controls the network settings as well as enabling how and what data is transmitted through the plugin.
Contents
Overview
When Witness generates events, such as alarms, or processes targets, it passes all this information to the Integration Manager. The Integration Manager is then able to use loaded plugins such as ICD-001 to convert this information into a suitable data format to send to external systems. In this case the plugin converts the data to XML message which are transmitted over a TCP/IP connection.
The data is transmitted as the events occur, leading to real time reporting.
Installing the ICD-001 Plugin
Witness supports integration with many different types of external systems through the use of plugins. These are stand-alone software libraries which are dynamically loaded by the Integration Manager and contain code which knows how to convert the Witness data into the required format for the external system. Navtech Radar can easily develop bespoke plugins to interface with a specific type of equipment or application, however ICD-001 has been developed to provide a comprehensive communication protocol which is based on open standards in order to make it as easy as possible to integrate with a large number of different systems.
The plugin can be selected during setup and will automatically be installed in the correct location.
When installing Witness, in the Choose Components page of the Witness Setup wizard, open Integration Plugin options and select ICD001:
Configuring the ICD-001 Plugin
When the plugin is installed and licensed, a plugin configuration with default settings is automatically generated.The settings can be viewed and edited by enabling the Config Function, then selecting the plugin in Integration Configurations, within the Configuration Tree. Configuration settings will then be available in the Configuration Panel.
Once you have made changes to the plugin configuration and committed the changes by saving, the plugin will automatically restart itself based on the new configuration. Note that any connections to 3rd party systems will be dropped during this restart.
The setting options are as follows:
Enable Plugin: when enabled the plugin will start and will always start when the Witness system starts. When disabled the plugin will stop and will not start until re-enabled.
Plugin Name: user friendly name of the plugin.
Sender Id: numeric Id used to identify this plugin for incoming tracks. This allows track detections passed into Witness via the ICD-001 plugin to be identified has having come from this plugin.
Alarm Priority: this acts as a filter for alarm reports. Only alarms of the same or higher priority will be sent out through the plugin.
TCP Port: The TCP port on which the plugin listens to connections from clients.
Max Clients: The total number of network clients supported by the plugin.
Track Output Mode: sets the track output filter:
None - no tracks reports are sent.
Broken Rule - report all tracks which have broken rules, regardless of whether this resulted in an alarm.
Alarm Only - report only tracks which have broken rules that results in an active alarm.
All - reports all tracks.
Buffer Tracks: when enabled this will force tracks to be buffered and sent in batches based on the Track Buffer Timer. This can optimise network load but has the drawback of not sending data in real time. The Track Buffer Time setting specifies how often the buffered tracks are sent.
Status Reports: when enabled this will trigger status reports to be sent at a regular interval based on the Status Report Time. In addition it allows status reports to be sent when any status changes (i.e. health or system profile). This also enables support for the Request Status Command which provides the capability for external systems to request status reports. For more information please click here.
Area Report Filter: this sets the filter for the area status report. One or more area types can be selected. This filter can be useful when a site has a lot of areas of different types. This filter ensures the status report only includes relevant areas. By default only Alarm areas are reported. If you do not wish to report any area status data then you clear the selection on all types.
Alarm Reports: when enabled, Alarm Reports will be sent when alarms are raised. For more information please click here.
Camera Reports: when enabled, Camera Reports will be sent when cameras are tasked to follow targets. For more information please click here.
Classification Reports: when enabled, the Classification Report will contain the statistics for each configured section and classification type. For more information please click here.
Carriageway Statistics Report: when enabled, the Carriageway Statistics Report will contain the statistics for each section. For more details please click here.
Carriageway Statistics Interval (s): This setting specifies how often the Carriageway Statistics are sent.
Track Buffer Timer (s): period of time between each batch of tracks being sent if Buffer Tracks is enabled.
Heartbeat Timer (s): the interval at which heartbeats are sent to the connected clients.
Status Report Timer (s): the interval at which each status report is sent. when the Send Status option is enabled.
If you want to enable the status report mechanism but do not want to send regular automatic reports then you can set the Status Report Timer to 0 (zero).
Monitor Client Health: when enabled, the plugin will monitor the health of client connections. If a client is either not connected or connected but not sending heartbeats, then an alarm will be raised in Witness. The client must support sending heartbeats to Witness to use this option.
Allow Trace Logging: enables trace logging for diagnostics purposes.
Use TLS: enables TLS for the network connection. When disabled the link does not use any authentication or encryption. When enabled there are additional configuration options:
Authentication Type: the authentication method to use for the TLS connection:
a. None - no authentication is used however the link is still encrypted using TLS with a self-signed certificate created by Witness.
b. Fingerprint - this option can be used with self-signed certificates. This will look for client certificates with matching thumbprints on the server’s Windows certificate store. You can store more than one thumbprint in order to support a different certificate per client.
c. Certificate - this option uses a certificate with a fully verifiable certificate chain and Certificate Authority (CA). Typically this will need the full certificate chain including the CA root certificate available in the Windows certificate store or verifiable through a network connection.
Fingerprint Authentication
This is a simple way to authenticate clients when using self-signed certificates that can’t be verified using a Certificate Authority (CA).
Although these certificates can be self-signed, they are not auto-generated by Witness because they are being used for authentication. These certificates must be created manually and then installed onto the client and server PCs. The server will look for client certificates within its own certificate store and the client should check for the server certificate which should installed on the client PC.
Certificate Thumbprint: the thumbprint of the server certificate to use for the TLS connection.
Current User Store: indicates if the certificate should be fetched from the current user store, if not it will be fetched from the local computer store.
Client Thumbprints: this is the list of client thumbprints. These are used to authenticate client connections. Each of these certificates must be installed in the certificate store on the server. Each entry can added with name for easy identification of the certificate.
Certificate Authentication
This is the standard way of authenticating a certificate using a Certificate Authority (CA) typically through a CA root certificate.
Certificate Thumbprint: the thumbprint of the server certificate to use for the TLS connection.
Current User Store: indicates if the certificate should be fetched from the current user store, if not it will be fetched from the local computer store.
Product Specific Settings
ClearWay™
Send Size Classification Report: when enabled ClearWay™ Size & Classification Reports will sent if Traffic Analysis is enabled.