ICD-001 Communication
- Guy Avery (Deactivated)
- Charlotte Dakin-Norris
- Benedict Dakin-Norris (Unlicensed)
Introduction
This document does not cover the specifics of the messaging transport mechanism. It is assumed that a suitable network link is available between the Navtech system and third-party. The ICD-001 interface in Witness now supports TLS 1.2. This is optional but we recommend its use if you are concerned about the security of the network link between Witness and your application. The interface supports both self-signed and certificates issued from a recognised CA. By default self-signed offers encryption without authentication, however you can manually install self-signed certificates and use the thumbprint check to enforce authentication as well. Installing certificates issued from a recognised CA will always use authentication and encryption.
Contents
Establishing Communications
This release of this ICD will only support data supplied from new Witness system. There is no backwards compatibility with older releases. Older documentation can be provided for customers on maintenance. Please contact Navtech Customer Support for more help.
There is no formal handshake to establish communications. A TCP port will be opened on a specified IP address to listen for and send out data. Whether data is automatically transmitted and what type of data is sent is decided using the configuration of the Witness system. When subscribers wish to receive data they simply connect to the relevant IP and port. The limitation of this approach means that subscribers have no control over what data they receive; once they connect they will receive any report that is issued.
When using TLS, there is a formal, secure handshake which is part of the TLS protocol. If using formally issued certificates or the thumbprint check mechanism, the initial connection process will authentication using these certificates.
Message Framing
All messages are sent as a UTF8 byte stream with a message header that defines the message signature, type, version and content length.
Message Details
All messages consist of a minimum of 10 bytes (header) in the following format:
Section | Header | Content | |||||||||
Byte Index | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10+ |
Description | Signature | Version | Type | Length of Content (Network Order / Big Endian) | Content | ||||||
Type | byte | byte | byte | int (4 bytes) | byte[] | ||||||
Value | AA55 | 1 | See 6.2 | ||||||||
Message Types
Value | Description |
0 | Xml Document |
1 | Heartbeat. No content is required |
Please note that the byte order of all the fields are based on Big Endianness (Network Order). Currently this only applies to the 4 byte length field in the message header.
Related Information
-
ICD-001 Track Filter Command (Witness 4.0)
-
ICD-001 Acknowledge Alarm Command (Witness 4.0)
-
ICD-001 Request Status Command (Witness 4.0)
-
ICD-001 Detection Command (Witness 4.0)
-
ICD-001 Update Entity Command (Witness 4.0)
-
ICD-001 System Profile Command (Witness 4.0)
-
ICD-001 External Trigger Command (Witness 4.0)
-
ICD-001 Plugin (Witness 4.0)
-
ICD-001 Command Reply (Witness 4.0)
-
ICD-001 Camera Command (Witness 4.0)