ICD-001 Communication

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

 

Safety is everything.